Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/41540/

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 9d36a74:

Support of ESTree class features is still experimental, Babel may change the class features AST if, when the ESTree proposal merged, the AST shapes differs, though it is very unlikely as far as I know.

Do we know how we want to handle a situation like this? Are we going to wait until major versions to change the AST or add options or something? Just want to make sure we don't break any plugins that rely on the current AST shape.

So far we have always considered these changes as "new features" and shipped them in minors enabled by default: the contract of the "estree" option is "I want Babel to generate an AST that respects the ESTree spec", so if the ESTree spec changes not aligning with it is a bug (similarly, when the ECMAScript spec changes we introduce the breaking change to align as a bugfix).

However, I wouldn't be opposed to something like ["estree", { "classFeatures": true }] until Babel 8.

The class features ESTree proposal has been moved to stage 3 recently: estree/estree#242, which means unless the spec undergoes significant change, the current ESTree AST shape will not change. See also https://github.com/estree/estree/blob/master/stage3/README.md

Q: Does eslint support this natively now?

I haven't been involved in a few months, but, last I checked, ESLint's policy is to not crash on stage 3 syntax. Rules aren't updated for new syntax until they hit stage 4.

No, sadly they're still insisting on waiting til stage 4 to support things that have already shipped in browsers and node.