Every single ECMAScript edition should have an "env" option

es7/es2016 adds no new globals - that means that there’s no “env” option for it.

This is confusing, because users don’t know these details, and don’t want to have to think about it - a user should be able to set their ecmaVersion and env to, say, “es2016” or “es2017” and have eslint do the Right Thing™.

If there are no new globals in a year, then great - es2016’s globals are the same as es2015’s - but that’s not something the user writing the eslint config should have to care about.

(opening a new issue per https://github.com/eslint/eslint/issues/8453#issuecomment-322266500)

[ljharb]

Yes, let’s please reopen this. It’s very confusing to have a discontinuous set of editions.

[MatthewHerbst]

@skylize for the record, I’m the original original OP 😄

Having followed the discussion for a while, I think a middle ground can be reached.

I agree with @not-an-aardvark that having the two decoupled can be extremely valuable to certain users. I also agree with @skylize that for most users, they just want to set the one thing and be done with it (i.e., they don’t distinguish between using say es2018 globals and es6 syntax - usually because they have something like babel transpiring the syntax anyways).

I propose a middle ground solution:

I think part of the problem is that today, env is confusing. As @ilyavolodin notes above, env should control the entire environment. So, let’s make that clear:

• env should be the single, well-document, Just Works^TM option that the average Joe/Mary user sets
  • Setting env to say, es2018 should allow both es2018 globals and es2018 syntax
• For power users:
  • The parserOptions should remain as is. Setting this value tells eslint to allow the syntax for that version, but says nothing about allowing globals from that version
  • A new option, globals, should be added. This will tell eslint to recognize the globals from a particular version
  • Setting both parserOptions and globals will cause env to be ignored
  • Setting only one of parserOptions or globals will cause the default for the other to be used
    • So, in the future case where we upgrade the defaults to es6, setting globals to es2018, but not setting parserOptions, will allow es2018 globals, but syntax will still be at es6
    • Similarly, setting parserOptions to es2018, but not setting globals, will allow es2018 syntax, will allow es2018 syntax, but globals will still be restricted to es6

I think this allows both the flexibility for power users that @not-an-aardvark desires, and the simplicity for average users that @skylize desires.

This does break the way env works in a big way, and it could be a bit painful in terms of reading docs (though no code other than configs should have to be changed) for users to upgrade to the new version. But I think the long-term durability and stability works for most stakeholders.