`esversion` option #2519

nicolo-ribaudo · 2015-07-02T21:24:53Z

No description provided.

lukeapage · 2015-07-02T22:03:24Z

src/jshint.js

@@ -4247,12 +4305,12 @@ var JSHINT = (function() {
    x.lbp = 25;
  }(prefix("yield", function() {
    var prev = state.tokens.prev;
-    if (state.inESNext(true) && !state.funct["(generator)"]) {
+    if (state.inES6(true) && !state.funct["(generator)"]) {


generator functions aren't in 6.. but I guess the plan for this is for v2.x.. meaning it cannot break?
Still might be good to differentiate now e.g. esnext means esversion = 7 and this requires es7?

generator functions aren't in 6

Do you mean generator comprehensions?

Still might be good to differentiate now e.g. esnext means esversion = 7 and this requires es7?

If you mean the esnext option, it would be a breaking change...

Okay, im doubting myself now, but anyway the gyst is...
Any es7 features should only be on in esversion = 7 and esnext should map to esversion 7. That way esversion is "correct" and it is not a breaking change..

Sorry for the confusion, generators did make es6, this thread only applies to arrray comprehensions.

Done, but I've not yet documented esversion: 7 becasue of #1939 (comment)

lukeapage · 2015-07-02T22:09:32Z

Not all the comments are for you, some are just things that probably need "deciding" by someone (so probably @jugglinmike). I wouldn't do anything based on them yet till he responds and its too risky a changeset for me to consider merging, so I'll be leaving it to him.
Thanks though - its a step forward.

lukeapage · 2015-07-02T22:11:32Z

src/jshint.js

@@ -2589,11 +2647,11 @@ var JSHINT = (function() {
  prefix("[", function() {
    var blocktype = lookupBlockType();
    if (blocktype.isCompArray) {
-      if (!state.inESNext()) {
+      if (!state.inES6()) {
        warning("W119", state.tokens.curr, "array comprehension");


same here, not ES6

jugglinmike · 2015-07-02T23:24:34Z

We also need to decide what to do about the moz function.. in v3 will it be there? will it be removed? if it will be removed, then this PR is doing the right thing

We're going to keep moz, but as proposed in gh-1148, we should deprecate the dedicated option and include a "moz" value for esversion. Today, it can be taken to mean "ES6 plus Mozilla extensions". @nicolo-ribaudo would you be up for that in this patch?

(Moving forward, we will remove list comprehensions from ES6 but persist them in "moz".)

nicolo-ribaudo · 2015-07-03T14:16:46Z

@jugglinmike See #1148 (comment).

Since "moz" isn't standard ECMAScript, I think it shouldn't be included in esversion, but JSHint should complain when moz and esversion are used at the same time.

Another question: can esversion be changed after JSHint has parsed some code?

jugglinmike · 2015-07-03T14:41:47Z

Since "moz" isn't standard ECMAScript, I think it shouldn't be included in esversion, but JSHint should complain when moz and esversion are used at the same time.

I'm fine with this, but by the same token, 7 shouldn't be an accepted value of esversion.

Another question: can esversion be changed after JSHint has parsed some code?

No. You can re-use the logic I introduced for the module option to achieve this.

lukeapage · 2015-07-03T19:01:02Z

<opinion>

I dont like the moz option. We should remove let blocks since afaik they are a dead proposal, replaced by let proper and not have moz. Array comprehensions should go under 7 or esversion expeimental since afaik they are on the cards for 7/es2016. we could say it is not a breaking change for experimental to evolve..
If chrome implements comprehensions then we have a badly named option.
Imo if something like comprehensions is still on the standards track there is no point removing it unless its hurting or causing issues or we are planning a big refactor

 </opinion>

nicolo-ribaudo · 2015-07-04T20:15:28Z

I dont like the moz option. We should remove let blocks since afaik they are a dead proposal, replaced by let proper and not have moz.

Removing moz would be a very very breaking change, I don't think it would ever be done

we could say it is not a breaking change for experimental to evolve..

It would be a bug not evolving following proposals, but implementing an older version of them 😉

I'm fine with this, but by the same token, 7 shouldn't be an accepted value of esversion.

I think esversion: 7 would be more intuitive than esversion: moz

(NOTE: Making moz a value of esversion would be easier than using two separate options)

jugglinmike · 2015-07-04T21:35:21Z

I dont like the moz option.

I'm not a fan of it either, but it's a commitment that was made for us, and we should honor it so long as it doesn't impede continued development. I have no idea what the active usage is like, but a simple GitHub code search suggests that removing it would put a lot of people off.

I think esversion: 7 would be more intuitive than esversion: moz

It's not about intuitiveness, it's about correctness. ES7 doesn't exist yet, and when it does, it will be a moving target. It should be considered experimental and exposed in a way that makes this clear. Definitely out-of-scope for this patch, though.

nicolo-ribaudo · 2015-07-05T10:08:31Z

It's not about intuitiveness, it's about correctness. ES7 doesn't exist yet,

I've removed esversion: 7, and esversion: 6 still doesn't enable array comprehensions.

Definitely out-of-scope for this patch, though.

I agree with you

nicolo-ribaudo · 2015-07-05T12:38:46Z

Before last commit, linting this code:

// jshint esversion: 3
// jshint moz: true
var a = {
  get x() {}
};

JSHint warned that getters are es5 features, even if moz is > than ES5

lukeapage · 2015-07-05T21:11:27Z

JSHint warned that getters are es5 features, even if moz is > than ES5

I remember seeing plenty of bugs about people not realising they had to have moz and es5/esnext on, but I think they were mostly in reference to a previous breaking change.

nicolo-ribaudo · 2015-07-06T21:19:23Z

Should tests use esversion instead of es3/5/next?

lukeapage · 2015-07-07T06:57:01Z

Should tests use esversion instead of es3/5/next?

I think so.. it needs to be done at some point anyway. It seems like alot of hassle so you might want to wait for @jugglinmike's opinion.

jugglinmike · 2015-07-07T14:15:39Z

I'd rather not since it adds a lot of noise to the non-trivial change happening here. I think that change would fit better in a single "Remove version-specific language options" commit, somewhere down the line

lukeapage · 2015-07-08T08:05:06Z

@nicolo-ribaudo you might be interested to see Mike's blog post on jshint's way forward w.r.t. esversion - http://jshint.com/blog/new-lang-features/
It looks to me like this PR matches what was said.

nicolo-ribaudo · 2015-07-08T13:33:29Z

I think I can revert ~~4758744~~ 1d97511

@nicolo-ribaudo you might be interested to see Mike's blog post on jshint's way forward w.r.t. esversion - http://jshint.com/blog/new-lang-features/

Thanks for the link

nicolo-ribaudo · 2015-07-08T17:15:20Z

Rebased on master to resolve merge conflicts.

jugglinmike · 2015-08-08T18:16:46Z

@nicolo-ribaudo This patch no longer merges cleanly, but it doesn't seem fair to ask you to rebase again. I've squashed the commits together and added a single merge commit to resolve the conflicts; you can find that on the esversion-option branch of my fork: https://github.com/jugglinmike/jshint/tree/esversion-option

If that looks good to you, I can either squash those commits together or land them as-is. Or, if you prefer, you can of course resolve the conflicts yourself. Please let me know how you'd like to proceed.

I'm sorry I let this go for so long!

nicolo-ribaudo · 2015-08-09T14:15:53Z

@jugglinmike I won't be able to rebase this until next weekend.
If this commit is needed sooner, feel free to merge your branch as-is.

This option (which may be set to 3, 5, or 6 / 2015) should replace `es3`, `es5` and `esnext`. This: - precludes invalid configurations like `es3: false, es5: true` - scales better for future versions of ECMAScript - eliminates the ambiguity of `esnext` (whose meaning has changed now that ES6 has been finalized) This commit partially fixes jshint#2124

Now "esnext" means es7

…rsion: 6`

nicolo-ribaudo · 2015-08-14T11:13:09Z

@jugglinmike Rebased, to not introduce noise (the merge commit) in commits history.

jugglinmike · 2015-08-15T20:05:28Z

Rebased, to not introduce noise (the merge commit) in commits history.

A man after my own heart.

Squashed and merged to master at commit cf5a699. Thanks, Nicolò!

…ne `esnext` This commit fixes a regression introduced in jshintgh-2519

…ne `esnext` This commit fixes a regression introduced in gh-2519

…ne `esnext` This commit fixes a regression introduced in jshintgh-2519

lukeapage reviewed Jul 2, 2015
View reviewed changes

lukeapage added the Needs review label Jul 2, 2015

lukeapage reviewed Jul 2, 2015
View reviewed changes

lukeapage added Needs work and removed Needs review labels Jul 3, 2015

nicolo-ribaudo force-pushed the esversion-option branch from a83c622 to db91f99 Compare July 5, 2015 10:04

lukeapage added Needs review and removed Needs work labels Jul 6, 2015

nicolo-ribaudo force-pushed the esversion-option branch from 1205c91 to 0ed24c5 Compare July 8, 2015 17:15

lukeapage added the Good to land label Aug 8, 2015

lukeapage removed the Needs review label Aug 8, 2015

nicolo-ribaudo added 4 commits August 14, 2015 11:25

Hint 'esversion: 6' instead of 'esnext: true' in W104 and W119

fecf65e

Array comprehension is es7 or moz, not es6

a5e37e4

Now "esnext" means es7

Make ECMAScript version configurable in W104 and W119

dc0672c

nicolo-ribaudo force-pushed the esversion-option branch from 0ed24c5 to 22bbf39 Compare August 14, 2015 10:46

nicolo-ribaudo added 4 commits August 14, 2015 13:06

The esversion option cannot be set after any executable code

8765c96

Revert commit 719a896, array compehensions aren't enabled using `esve…

2269769

…rsion: 6`

Correctly swap between moz and esversion

59d6613

Correctly swap between moz and esversion - 2

4f1eeb9

nicolo-ribaudo force-pushed the esversion-option branch from 22bbf39 to 4f1eeb9 Compare August 14, 2015 11:09

jugglinmike closed this Aug 15, 2015

nicolo-ribaudo deleted the esversion-option branch August 15, 2015 22:30

nicolo-ribaudo added a commit to nicolo-ribaudo/jshint that referenced this pull request Aug 26, 2015

[[FIX]] Allow binary and octal numbers, and templates when using inli…

9f66a4b

…ne `esnext` This commit fixes a regression introduced in jshintgh-2519

nicolo-ribaudo mentioned this pull request Aug 26, 2015

[[FIX]] Allow binary and octal numbers, and templates when using inline esnext #2645

Closed

jugglinmike pushed a commit that referenced this pull request Aug 27, 2015

[[FIX]] Allow binary and octal numbers, and templates when using inli…

b5ba7d6

…ne `esnext` This commit fixes a regression introduced in gh-2519

jugglinmike pushed a commit to jugglinmike/jshint that referenced this pull request Sep 20, 2015

[[FIX]] Allow binary and octal numbers, and templates when using inli…

414432f

…ne `esnext` This commit fixes a regression introduced in jshintgh-2519

rwaldron mentioned this pull request Aug 31, 2016

Bad option: 'esversion' #3024

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

`esversion` option #2519

`esversion` option #2519

nicolo-ribaudo commented Jul 2, 2015

lukeapage Jul 2, 2015

nicolo-ribaudo Jul 2, 2015

lukeapage Jul 3, 2015

lukeapage Jul 3, 2015

nicolo-ribaudo Jul 3, 2015

lukeapage commented Jul 2, 2015

lukeapage Jul 2, 2015

nicolo-ribaudo Jul 3, 2015

jugglinmike commented Jul 2, 2015

nicolo-ribaudo commented Jul 3, 2015

jugglinmike commented Jul 3, 2015

lukeapage commented Jul 3, 2015

nicolo-ribaudo commented Jul 4, 2015

jugglinmike commented Jul 4, 2015

nicolo-ribaudo commented Jul 5, 2015

nicolo-ribaudo commented Jul 5, 2015

lukeapage commented Jul 5, 2015

nicolo-ribaudo commented Jul 6, 2015

lukeapage commented Jul 7, 2015

jugglinmike commented Jul 7, 2015

lukeapage commented Jul 8, 2015

nicolo-ribaudo commented Jul 8, 2015

nicolo-ribaudo commented Jul 8, 2015

jugglinmike commented Aug 8, 2015

nicolo-ribaudo commented Aug 9, 2015

nicolo-ribaudo commented Aug 14, 2015

jugglinmike commented Aug 15, 2015

esversion option #2519

esversion option #2519

Conversation

nicolo-ribaudo commented Jul 2, 2015

lukeapage Jul 2, 2015

Choose a reason for hiding this comment

nicolo-ribaudo Jul 2, 2015

Choose a reason for hiding this comment

lukeapage Jul 3, 2015

Choose a reason for hiding this comment

lukeapage Jul 3, 2015

Choose a reason for hiding this comment

nicolo-ribaudo Jul 3, 2015

Choose a reason for hiding this comment

lukeapage commented Jul 2, 2015

lukeapage Jul 2, 2015

Choose a reason for hiding this comment

nicolo-ribaudo Jul 3, 2015

Choose a reason for hiding this comment

jugglinmike commented Jul 2, 2015

nicolo-ribaudo commented Jul 3, 2015

jugglinmike commented Jul 3, 2015

lukeapage commented Jul 3, 2015

nicolo-ribaudo commented Jul 4, 2015

jugglinmike commented Jul 4, 2015

nicolo-ribaudo commented Jul 5, 2015

nicolo-ribaudo commented Jul 5, 2015

lukeapage commented Jul 5, 2015

nicolo-ribaudo commented Jul 6, 2015

lukeapage commented Jul 7, 2015

jugglinmike commented Jul 7, 2015

lukeapage commented Jul 8, 2015

nicolo-ribaudo commented Jul 8, 2015

nicolo-ribaudo commented Jul 8, 2015

jugglinmike commented Aug 8, 2015

nicolo-ribaudo commented Aug 9, 2015

nicolo-ribaudo commented Aug 14, 2015

jugglinmike commented Aug 15, 2015

`esversion` option #2519

`esversion` option #2519