[JavaScript] Add support for class fields

[Thom1729]

Implements the class fields proposal. See #1269 for more discussion. Also resolves #1238 and partially resolves #876.

Outline of changes:

• No longer recognize the static keyword in object literals. It should be interpreted as an identifier.
• In classes, rescope static as storage.modifier. It was previously scoped as storage.type.
• Recognize class property declarations and initializers in class bodies.
• Recognize private class properties in expressions.

Relevant to tc39/proposal-class-fields#57.

[wbond]

I very much appreciate all of the work you've been doing on the JavaScript syntax recently. I know lots of users are benefitting from your hard work.

I think that #1269 outlines that this currently has no implementations. I feel like once Babel or a browsers supports it, then I'd be more keen on merging it. Mostly because every feature we add increases the complexity, and having things in heavy flux implemented here are just going to make things more complicated in the future. Contributors will have to dig through history to understand why the implementation is as it is.

Perhaps we can merge in some of the foundational stuff in now and leave the proposals in a PR for once there is someone implementing them?

[Thom1729]

Public class fields are implemented in Babel and are widely used. Private fields are implemented in Babel's parser, but the transform is not yet finished.

In addition, the entire spec (including private fields) is at Stage 3, which means that it should be very stable. It probably won't move to Stage 4 until after it's actually shipping in major browsers. (Stage 4 requires "Two compatible implementations which pass the acceptance tests", although one of them may be a transpiler like Babel.) Expected changes are "Limited: only those deemed critical based on implementation experience". In the unlikely event that there are any changes to the proposal, it is even more unlikely that the syntax would be affected; late-stage changes tend to be esoteric tweaks to obscure semantics.

On the other hand, in my experience there are a lot of developers actively using class fields, including my own company. Without explicit support in the sublime-syntax, highlighting of JavaScript with class fields fails quite ungracefully. This severely impacts the usability of the JavaScript syntax when using class fields. Because class field declarations may contain arbitrary expressions, I don't believe that there is any way of ignoring them without fully and properly parsing them, at which point we may as well give them the appropriate scopes as well.

If we want to be maximally conservative, what about commenting out private field support until Babel supports it?

[Thom1729]

Just to add on to this: I would suggest that a conservative standard might be that we should implement "experimental" features when:

• The feature is at Stage 3 status; OR
• The feature is at Stage 2, AND there is a working implementation, AND the syntax risk is Low.

Stage 3 is the gold standard indicating that a feature is ready for implementation. It must have a complete formal specification and sign-offs from various reviewers and editors. In addition, "The solution is complete and no further work is possible without implementation experience, significant usage and external feedback." This is the point at which most major browser vendors will begin shipping the feature, and indeed it cannot advance to Stage 4 without "[t]wo compatible implementations which pass the acceptance tests" and "[s]ignificant in-the-field experience with shipping implementations".

Stage 2 means that a feature is largely complete, but not totally finalized. It is required that "all major semantics, syntax and API are covered", and "[t]he committee expects the feature to be developed and eventually included in the standard". It is expected that features in Stage 2 will be implemented by transpilers and other tools and often by major browsers (usually behind dev flags). Having a working implementation means that actual developers will be using the feature in production code. Although it is possible for a feature's syntax to change at this stage, it is very unusual. The standards committee actively tries to avoid making changes that would break Babel, and from reading their meeting notes you can easily get a sense of whether there is any significant syntax risk.

[Thom1729]

@wbond Any thoughts on the standard described above?

[wbond]

@Thom1729 I think those standards for inclusion sound reasonable.