ES6 - Incorrect parsing for spread operator in object literals

[jRiest]

Seems like even with esnext:true JSHint is getting confused by using the spread operator in an object literal. The following code:

/* jshint esnext:true */
var first = { a: 'A', b: 'B' };
var second = { ...first, a: 'Different A'};

produces these errors:

Five warnings
3 Expected '}' to match '{' from line 3 and instead saw '...'.
3 Missing semicolon.
3 Expected an assignment or function call and instead saw an expression.
3 Missing semicolon.
3 Expected '(end)' and instead saw ':'.
One undefined variable
3 a
One unused variable
3 second

[rwaldron]

SpreadElement is not allowed in ObjectLiteral https://people.mozilla.org/~jorendorff/es6-draft.html#sec-array-initializer

[jugglinmike]

Oh thank goodness.

[sebmck]

Object Rest/Spread Properties is an ES7 proposal.

[rwaldron]

@sebmck Thanks, I'm very familiar with that document, and I'm also aware that's a level 0 proposal: https://github.com/tc39/ecma262

[sebmck]

@rwaldron I figured, just wanted to provide additional context for others.

[smfoote]

The spread operator is now a level 3 proposal (https://github.com/tc39/proposals). Any chance this issue can be reopened?

[el-davo]

Agree this should be re-opened. The object spread operator is pretty much fundamental to react/redux. Also eslint does support it. Unfortunately we will have to convert our legacy code to use eslint before enabling spread operator support unless this is fixed in jshint

[derwaldgeist]

+1

React/Redux code uses this a lot. Please support it (at least with an option like "esversion": 7). Thx!

[metasansana]

+1
Seems strange objects were left out.

[derwaldgeist]

Well, it's not officially standardized yet. But it probably will.

[jugglinmike]

This issue was filed at a time when the syntax was only just proposed. JSHint has a formal policy about support for new language features that is defined in terms of the TC-39 "stage" process, which is why this was closed at that time.

Since then, the proposal advanced to a stage that satisfied JSHint's requirements for inclusion. A new issue was subsequently filed to request the feature. Because this issue was already closed (and worded confusingly by suggesting that the current behavior was a bug), we elected to track the feature request with the new issue.

Recent activity on this issue indicates some confusion about the status of that feature request, so I am going to lock this conversation thread.

Long story short: if you're interested in this feature, please see gh-2991.