Jshint: Object "spread" properties (stage 2 proposal) not supported

Created on 30 Jul 2016  ·  27Comments  ·  Source: jshint/jshint

I got something like this

  args: {
    ...connectionArgs,
  },

And jshint its complaining about
xpected '}' to match '{' from line 167 and instead saw '...'.

What should i add to my .jshintrcfile to allow destructing?

Has PR P1 Proposal

Most helpful comment

+1 for supporting this. It's already widely used in React/Redux

All 27 comments

JSHint does not currently support this proposed language feature. It recently reached "Stage 2" in the standardization process, though, so we are interested in adding support in a future version.

Oh thank you @jugglinmike, any idea about how can i make jshint ignore it at least?

Sure, you'll want to use the in-line directives jshint ignore:start and jshint ignore:end:

  args: {
+   // jshint ignore:start
    ...connectionArgs,
+   // jshint ignore:end
  },

I've updated the issue title to more accurately describe the feature request.

Would be great to have JSHint support for this, since it's now Stage 3

+1 for supporting this. It's already widely used in React/Redux

+1. Is anyone working on this?

+1 for getting this done. Thanks guys!

+1 would enjoy this very much

+1

+1

Support for this language feature has been merged to the v2.10.0 feature branch (via gh-3150), so we expect it to be included in the next minor release of JSHint. I'll label this issue as "has PR" to better communicate this status.

Just a few days ago they announced:

Support for this language feature has been merged to the v2.10.0 feature branch (via gh-3150), so we expect it to be included in the next minor release of JSHint. I'll label this issue as "has PR" to better communicate this status.

But this is how I fixed it:

Add BOTH esnext and esversion to your .jshintrc file:

...
"esnext": true,
"esversion": 6,
...

Here is my full .jshintrc file:

{
    "mocha": true,
    "freeze": true,
    "bitwise": false,
    "browserify": true,
    "strict": true,
    "worker": true,
    "scripturl": true,
    "latedef": "nofunc",
    "onevar": true,
    "node": true,
    "maxstatements": 25,
    "futurehostile": true,
    "noarg": true,
    "unused": true,
    "esnext": true,
    "esversion": 6,
    "eqeqeq": true,
    "nocomma": false,
    "devel": true,
    "maxdepth": 6,
    "jquery": true,
    "browser": true,
    "debug": true,
    "maxparams": 5,
    "undef": true,
    "globalstrict": true,
    "maxcomplexity": 20,
    "typed": true,
    "nonew": true,
    "forin": false,
    "shadow": true,
    "-W018": false
}

+1 can't wait for v2.10.0 to be released. Good job! Is there any timeline for v2.10.0?

When running [email protected]

When I have both

{
  "esnext": true,
  "esversion": 6,
}

I get the following error:

Incompatible values for the 'esversion' and 'esnext' linting options. (0% scanned).

Same here re: Incompatible values for the 'esversion' and 'esnext' linting options. (0% scanned).

What's the timeline for 2.10.0?

I also get Incompatible values for the 'esversion' and 'esnext' linting options even after installing directly from the v2.10.0 branch on GitHub. The error goes away when I omit esversion altogether. Here is a snippet from my .jshintrc, now:

"esnext": true,
"unstable": {
  "objspreadrest": true
},

The idea of that error is really "don't use both 'esversion' and 'esnext' (or 'es3', or 'es5'), afaiu.

The text could be clearer, but the goal of the error seems to be "emit warnings so that eventually we can remove these options and people just use 'esversion').

@jugglinmike do you think we should just make it a non-fatal error instead, or otherwise allow explicit 'esversion' to override the legacy version options?

@chaddjohnson That branch is available to promote transparency and to enable collaboration. You are of course welcome to run any code in this project, but please understand that we do not endorse the use of unreleased code because we do not have the bandwidth to support it.

@caitp I'd prefer to disallow ambiguity rather than attempt to interpret it. I'll share more detail in a response to your pull request.

https://github.com/jshint/jshint/issues/2991#issuecomment-349636400

[jshint] Incompatible values for the 'esversion' and 'esnext' linting options. (0% scanned). (E059)

https://github.com/jshint/jshint/issues/2991#issuecomment-396695974

[jshint] Bad option: 'unstable'. (E001)

@jugglinmike Then do you mean to say that it's impossible right now to use jshint?

Not at all, @NatoBoram. I'm discouraging the use of unpublished versions of the project.

Hmmm as anyone found a solution for the:

Incompatible values for the 'esversion' and 'esnext' linting options. (0% scanned). (E059)

any resolution of this ? when will jshint support LATEST syntaxes ?

Any word on this? I really appreciate this tool, but needing to litter my scripts with "ignore" comments is the worst.

Would someone have time to take a look at this? I'm running 2.9.7 which is the latest version of jshint, inside Atom editor, and my React Native app code is littered with syntax errors about the spread operator in object literals. Setting "esnext":true in .jshintrc doesn't help. The tool refuses to work when both "esnext":true and "esversion":6 are set.

If anyone has a workaround that works right now, would you please post it?

Support for this feature will be available in JSHint version 2.10.0 which we expect to release early next
week
. I'll mark this issue as "resolved" once that's published.

We just released support for object rest/spread in JSHint version 2.10.0.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Daniel-Hug picture Daniel-Hug  ·  3Comments

ghost picture ghost  ·  5Comments

TheSavior picture TheSavior  ·  3Comments

SidNM picture SidNM  ·  7Comments

voronianski picture voronianski  ·  8Comments