Destructuring with get or set causes "Unexpected token" error.

[rwjblue]

When using --esnext option: destructuring assignment with the keys get or set result in an "Unexpected token" error.

Example syntax that triggers the error:

// Using `set`
let { set } = Foo;

// Using `get`
let { get } = Bar;

Actual output:

% jscs --esnext get-set-parse-error.js
Unexpected token = at get-set-parse-error.js :
     1 |let { get } = Foo;
---------------------^
     2 |

1 code style error found.

[hzoo]

Since it's saying unexpected token, then it's most likely an esprima issue? We'll have to wait on a change there if so.

[rwjblue]

@hzoo - Yeah, makes sense. Should I close and reopen there?

[hzoo]

Yeah , I guess just check if they are already working on supporting it or if it's a bug?

[rwjblue]

This seems to parse properly with Esprima 2.2.0. See this online demo for an example.

[hzoo]

Ok then maybe the esprima used in jscs for esnext isn't the latest? @markelog

    "esprima": "^1.2.5",
    "esprima-harmony-jscs": "1.1.0-bin",

I think we are planning on updating to 2.2 if we didn't already and eventually making esnext default in 2.0. One option is to use the esprima option - you would need esprima as a dependency and use that instead of the one in jscs.

in package.json

"esprima": "~2.2.0",

in .jscsrc

"esprima": "./node_modules/esprima",

[rwjblue]

@hzoo - Awesome, thank you for the work around!!

[rwjblue]

A little follow-up:

• A more updated version of estraverse is needed to use with 2.2.0 of Esprima (which is easy to fix).
• Esprima 2.2.0 (and master) do not support parsing spread arguments yet, but the custom fork that JSCS uses does (must have been manually worked around?).

[qfox]

@rwjblue jquery/esprima#1099 — There is a roadmap for es6-features. I believe better to make all we need right in esprima core (to not repeat ourselves). 😼

[rwjblue]

@zxqfox - Yes, I completely agree. Unfortunately, we are in a weird position because some features that are needed (and are supported by other parsers) break parsing in both the custom fork that JSCS uses (let { get } = SomeThing;) and the main upstream Esprima version (someFunc(...someArray)) so we are forced to pick our poison (and decide what features are unsupported).

[rwjblue]

Also, is there an issue in JSCS-land for tracking the move to drop the custom fork of esprima-harmony in favor the main upstream version?

[qfox]

@rwjblue Well, if we should write something — better to write in upstream IMO.

But if it blocking something — it's another case and we should make something with our fork.

Also, is there an issue in JSCS-land for tracking the move

Not sure but we talking about it too often in past weeks.

[mikesherov]

@rwjblue I'll be working to get spread into Esprima this week hopefully.

[rwjblue]

@mikesherov - That is awesome! Thank you for your continued hard work both here, and in Esprima itself.

[hzoo]

Also, is there an issue in JSCS-land for tracking the move

Issues are #1382 (update esprima), #1353 (support babel)