Changing our parser options/ecmaFeatures

As part of looking at better supporting other parsers, I’ve been thinking a lot about how we’re configuring language features. Right now, everything is jam-packed into ecmaFeatures, something that only Espree supports, and it would be nice to create a more parser-agnostic way of configuring these features.

This proposal is not fully fleshed out, just looking to get some eyes on it.

Proposal

1. Remove all ecmaFeatures that are specific to ES6. Replace with ecmaVersion. Things like globalReturn, jsx, and experimental features would remain. This would also be a change in Espree.
2. Introduce sourceType that is "script" by default and can be set to "module".
3. Move these fields into a new parserOptions field in configuration.

Basically, we’d go from this:

        ecmaFeatures:
            arrowFunctions: true
            blockBindings: true
            regexUFlag: true
            regexYFlag: true
            templateStrings: true
            binaryLiterals: true
            octalLiterals: true
            unicodeCodePointEscapes: true
            superInFunctions: true
            defaultParams: true
            restParams: true
            forOf: true
            objectLiteralComputedProperties: true
            objectLiteralShorthandMethods: true
            objectLiteralShorthandProperties: true
            objectLiteralDuplicateProperties: true
            generators: true
            destructuring: true
            classes: true
            spread: true
            newTarget: true

To this:

parserOptions:
  ecmaVersion: 6
  sourceType: "module"    # if you want

Rationale

• ecmaVersion is supported already by escope, estraverse, and Acorn
• sourceType is supported already by escope, estraverse, Esprima, Espree, and Acorn
• Potential for some perf gains by eliminating a ton of if checks from Espree
• Most people are likely using es6 environment to enable all of ES6, so as long as the es6 environment switches parser options, then it should be no change for those users.
• Those who are using ecmaFeatures to disable specific features they don’t like can use no-restricted-syntax to catch most features and otherwise create small custom rules to forbid certain syntax.
• Third-party parsers could easily pass whatever options they wanted through configuration without us adding a special case.

Implications

• We’d remove context.ecmaFeatures in favor of context.parserOptions.
• Rules checking for context.ecmaFeatures.modules should check the sourceType property of the Program node instead.

[domenic]

I think this is really disappointing because it is perpetuating the fiction that is spec versioning throughout the tooling ecosystem. The year in which a feature is ratified by the European Computer Manufacturer’s Association should have no bearing on how people view it or use it in their projects.

Features should be considered independently of whatever official “spec version” they are bundled in; more relevant is whether they are supported in your target environment (e.g. Node, Chrome 49, Edge 12 vs. Edge 13 vs. IE11). Spec versions are a fiction, and have become as irrelevant to JS as they are to the rest of the web.

I recognize there are workarounds, and I fully intend to use them. But I’d urge you to reconsider the technical and philosophical implications of a change like this, which bundles features together by their absolutely least important aspect, for no good reason I can understand.

[mysticatea]

I have a plan to create a rule to restrict features to the specified target environment of Node.js (https://github.com/mysticatea/eslint-plugin-node/issues/5)

It might be good that a similar rule (more commonly) is created in core.