Update: add initial support for ES2018

[not-an-aardvark]

(Builds on #347, look at that first)

This adds support for ecmaVersion: 2018 (or ecmaVersion: 9). Currently, the only stage 4 proposal in ES2018 is the template literal revision, which Acorn now supports in 5.1.0.

[ilyavolodin]

Is it not too early to enable es2018 yet? Seems like a bunch more proposals should make it into final spec.

[not-an-aardvark]

I think we can still expose the option with the currently-available proposals, and add more features as necessary. This is the same thing that we did with the es2017 option last year.

[nzakas]

👎 This goes against the way we have handled ES updates. We haven't, and I'd argue shouldn't, be implementing any new ecmaVersion value until the spec is locked down. Doing otherwise means that we will constantly be introducing breaking changes anytime there's a change in the spec.

Our position has always been that we support the latest ratified version of ES only, and that for anything experimental you will need to use Babel. I'd like to see us continue on that path.

[not-an-aardvark]

I'm confused -- isn't this the same thing we've been doing before? We added support for async functions and trailing function commas last September, but ES2017 was officially locked down only a few months ago. I thought our position was to support stage 4 features, not wait for the yearly release schedule.

[mysticatea]

Yes, I believe we are supporting stage 4 syntax. Template literal revisions are stage 4 syntax of ES2018, so I think we should support it.

[ilyavolodin]

@not-an-aardvark I think the difference between what you and @nzakas is saying is "ratified" vs. "locked down". ES2017 was ratified just a few weeks ago, however, it was locked down in February (as in, no TC39 meetings between February and ratification date, so nothing can change at that point). ES2018 is pretty far from being locked down right now, so I really think it would make sense to wait a little, at least until closer to the end of the year.

[mysticatea]

@nzakas @ilyavolodin So, I have believed we are supporting stage 4 syntax, but it's wrong? At least, we immediately accepted async/await when it had become stage 4.

[mysticatea]

At least, we immediately accepted async/await when it had become stage 4.

It was July. Now is July as well.

[nzakas]

The thing we have always tried to avoid is the race to implement new ES features so we can avoid getting on the same hamster wheel that Babel is on. That's a very difficult path that takes a lot of work, as people barrage you with "it's stage 4 now, when will you support it?"

I think the ES2017 implementation was probably earlier than we should have done it. I know there was a lot of pressure to get async functions in and we (I) probably didn't feel like fighting any longer.

I do think we need a better strategy going forward. ES changes are not guaranteed to be 100% backwards compatible, and as such, if we start implementing ecmaVersion: 2018 piece by piece, we are effectively creating a breaking change each time (for both Espree and ESLint, we will be changing the meaning of ecmaVersion: 2018).

I realize our policy on how we add new features is ill-defined right now, so we should probably formalize it. My preference would be something like:

A new ecmaVersion is added once TC39 has officially closed down ECMA-262 changes for their yearly snapshot release.

(As Ilya pointed out, that happens months before ratification.)

Again, I'd rather let Babel-ESLint be the bleeding edge parser and keep Espree as a more stable one.

[mysticatea]

Thank you for the explanation.
But here, I prefer below since it's consistent with we have been doing:

• We accept issues/PRs of syntaxes which reached to stage 4. Because stage 4 syntaxes have 2 or more implementations in the real world, so it's stable and available for some people without transpiling. ES20xx specs are just snapshots at the time.
• We work for the syntaxes in the best effort until the syntax gets released as ES20xx spec (i.e., the next June) if no PRs. In this case, we have time between 4 months and 11 months.
• If somebody wants to use experimental syntaxes (stage 0-3), use babel-eslint.
• If somebody wants to use stage 4 syntaxes that we have not implemented yet, use babel-eslint or send the PR.

---

ES changes are not guaranteed to be 100% backwards compatible, and as such, if we start implementing ecmaVersion: 2018 piece by piece, we are effectively creating a breaking change each time (for both Espree and ESLint, we will be changing the meaning of ecmaVersion: 2018).

I don't think so.
Stage 4 is "Finished" specification, so it must satisfy the following conditions.
If a new syntax has breaking changes to us, I suspect it's "Break the Web".

• Test262 acceptance tests have been written for mainline usage scenarios, and merged.
• Two compatible implementations which pass the acceptance tests.
• Significant in-the-field experience with shipping implementations, such as that provided by two independent VMs.
• A pull request has been sent to tc39/ecma262 with the integrated spec text.
• The ECMAScript editor has signed off on the pull request.

https://tc39.github.io/process-document/

[mysticatea]

If a new syntax has breaking changes to us, I suspect it's "Break the Web".

I'm imaging our semver policy, I think that the support of new syntaxes should reduce errors.

[not-an-aardvark]

TSC Summary: This PR adds an ecmaVersion: 2018 option to espree, which enables all ES2018 syntax features that have reached stage 4. (Currently, only the template literal revision has reached stage 4.)

TSC Question: Should we add this now, or should we wait until ES2018 is locked down next year?

[btmills]

In the 2017-07-20 TSC meeting, we decided to accept new features once they reach stage 4.