please respect unicode strings you are given

esprima.parse('a = "привет"') clearly preserves unicode strings in the format supplied

{ type: 'Program',
  body: 
   [ { type: 'ExpressionStatement',
       expression: 
        { type: 'AssignmentExpression',
          operator: '=',
          left: { type: 'Identifier', name: 'a' },
          right: { type: 'Literal', value: 'привет', raw: '"привет"' } } } ] }

esgen(esprima.parse('a = "привет"')) clearly does not

a = '\u043F\u0440\u0438\u0432\u0435\u0442';

Technically these js-strings are equivalent, but why forego readability?

[michaelficarra]

@vkz

What does render safely mean?

We can’t have " in "-delimited strings. We can’t have a carriage return or a paragraph separator. To avoid these characters, we can just Unicode escape everything. It’s the same string. If you really want to avoid Unicode escapes, use {format: {escapeless: true}} as your escodegen options. But the only way to use the same escapes that you used in your original code is to use the {verbatim: "raw"} option.

[vkz]

var esprima = require("esprima"),
    esgen = require("escodegen").generate,
    uglify = require("uglify-js");

var exhibit1 = '"\0 \x00 \u0000 0 \x30 \u0030"',
    ast1 = esprima.parse(exhibit1),
    exhibit2 = "'привет'",
    ast2 = esprima.parse(exhibit2);

esgen(ast1);
uglify.AST_Node.from_mozilla_ast(ast1).print_to_string();

esgen(ast2);
uglify.AST_Node.from_mozilla_ast(ast2).print_to_string();

every time uglify-js does this horribly unsafe thing a puppy dies.

Having lost several hours of my life debugging this safe behaviour I feel some friendly trolling is warranted here. There’ll be many a poor sobs down the road tripping over this, I’m sure.

NB: Esprima and Escodegen have saved me countless hours, I use them daily and I am absolutely grateful to their authors and maintainers for keeping them open source and providing support.