ES2015 aliases for ES6?

[mjomble]

This is similar to #5169, but in a backwards-compatible way.

Basically, an ability to specify ecmaVersion: 2015 that would behave just like ecmaVersion: 6 without deprecating the value 6.
And an es2015 environment that would just be an alias for the es6 one.

I understand if you think the maintenance overhead from this isn't worth it, but I wanted to check first :)

[ljharb]

Since ES7/ES2016 was the last one that was colloquially referred to by the edition number, and ES2017 likely won't be called "ES8", this seems like a good idea - provided that "edition" support stops before edition 15 :-p (and to be safe, edition 9, since ES5 could potentially be referred to as ES2009).

[vitorbal]

Thanks for reaching out, @mjomble!
I don't know how much maintenance overhead would this imply (not very familiar with that part of the codebase yet), but agreed with @ljharb that this might be a good idea.

However I don't think this would be high in priority for the team since everyone is very focused on JSCS compatibility at the moment.

Would you be willing to work on a PR for this proposal if it gets accepted by the core team?

[mjomble]

I'd be interested in working on a PR, depending on how complex it ends up becoming :)

[vitorbal]

@mjomble Great!
We can accept this issue once someone on the ESLint team champions this and three other people endorse the change (with no one voting against it).
Hopefully we can get more feedback from the rest of the team soon.

[mjomble]

Cool :)

I've had a brief look at the code and having seen many checks like ecmaVersion >= 6, I think the first thing I'd do is add validation to the ecmaVersion option, locking it down to only accept a specific set of values, such as 3, 5, 6, 7, 2015 and 2016 - more could be added in future versions. And after that they could be converted to a normalized comparable form to avoid problems from 2015 being greater than 7, etc.

In theory, this might be a breaking change for anyone out there who for some reason is not using one of these values for ecmaVersion in their config. For example, someone might be currently using ecmaVersion: 8 and it would probably work fine until this value becomes rejected.

[nzakas]

@vitorbal that's not accurate. The champion+3 method of decision making is only for rules. For core features, TSC support is required.

Keep in mind that these features come through from Espree, so we'd need to determine whether or not to make changes there or if it makes more sense to make them just in ESLint.

[vitorbal]

Thanks, @nzakas, sorry for the mix up! I'll have that in mind from now on.

[nzakas]

Taking a quick look at the implementation -- escope also uses ecmaVersion, so it's best to normalize in ESLint so (so 2015 is converted to 6 and 2016 is converted to 7) before passing the value to escope or Espree.

I like the idea, will run it by the TSC for input.

[nzakas]

After a quick offline chat, the TSC is all 👍 for this, so marking as accepted.

@mjomble feel free to submit a pull request

[mjomble]

Excellent, will try to find time for this soon :)

[Mouvedia]

@ljharb I wouldn't be so sure about that.

It is the eighth edition of the ECMAScript Language Specification.

Only time will tell :)

[ljharb]

@Mouvedia just because editions will continue to be numbered has no bearing on whether people will colloquially use the term "ES8". Indeed, only time will tell.

[alberto]

@ljharb that's going to be a mess, which I think could be avoided if they were officially called ES15, ES16 (which some people will also use anyways)...

[ljharb]

@alberto unfortunately that ship has sailed.