esprima icon indicating copy to clipboard operation
esprima copied to clipboard

Optional raw identifiers

Open wisec opened this issue 7 years ago • 3 comments

Steps to reproduce

esprima.parse('var \u00e0;')

Expected output

{
  "type": "Program",
  "body": [
    {
      "type": "ExpressionStatement",
      "expression": {
        "type": "Identifier",
        "name": "\u00e0"
      }
    }
  ],
  "sourceType": "script"
}

Actual output

{
  "type": "Program",
  "body": [
    {
      "type": "ExpressionStatement",
      "expression": {
        "type": "Identifier",
        "name": "à"
      }
    }
  ],
  "sourceType": "script"
}

I didn't expect identifiers in unicode format to be transformed, which is okay of course, I would like to ask if an option to keep Identifiers and function names unencoded can be added.

Thanks!

wisec avatar Mar 12 '18 18:03 wisec

@wisec Your expected and actual examples are indistinguishable. Did you mean to have "name": "\\u00e0" in your expected example? If so, this would be a backward-incompatible change. That won't happen. More likely would be the addition of a raw field which includes a slice of the source text.

michaelficarra avatar Mar 13 '18 01:03 michaelficarra

@michaelficarra

Did you mean to have "name": "\\u00e0" in your expected example?

yes, sorry, I meant name:"\\u00e0"

If so, this would be a backward-incompatible change.

I was thinking something like:

esprima('var \\u00e0;',{rawidentifiers:true});

which I don't think it would be a breaking change since it's an option, besides that it would have a very low performance impact.

More likely would be the addition of a raw field which includes a slice of the source text.

That would work as well!

What do you think? I can create a PR if you are ok with one of the above propositions.

wisec avatar Mar 13 '18 07:03 wisec

I would not be okay with an option changing the return type. But the raw field seems good. 👍 send a PR.

michaelficarra avatar Mar 13 '18 15:03 michaelficarra