Changing our parser options/ecmaFeatures
See original GitHub issueAs 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
- Remove all
ecmaFeatures
that are specific to ES6. Replace withecmaVersion
. Things likeglobalReturn
,jsx
, and experimental features would remain. This would also be a change in Espree. - Introduce
sourceType
that is"script"
by default and can be set to"module"
. - 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 AcornsourceType
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 thees6
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 useno-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 ofcontext.parserOptions
. - Rules checking for
context.ecmaFeatures.modules
should check thesourceType
property of theProgram
node instead.
Issue Analytics
- State:
- Created 8 years ago
- Comments:18 (16 by maintainers)
Top Results From Across the Web
Migrating to v2.0.0 - ESLint - Pluggable JavaScript Linter
These changes are the direct result of feedback from the ESLint community of ... The ecmaFeatures property is now under a top-level parserOptions...
Read more >@typescript-eslint/parser - npm
Start using @typescript-eslint/parser in your project by running `npm i ... interface ParserOptions { ecmaFeatures?:
Read more >Configure parserOptions or parser package for ESLint and ...
This is the way I set it up in eslint-config-auto, which automatically configures eslint based on your package.json config.
Read more >Intro to ESLint Config Files - Mastering JS
The parserOptions config option tells ESLint what version of JavaScript you're targeting. ... ecmaFeatures.jsx to true as shown below.
Read more >eslint/eslint - Gitter
So do I have to enclose the ecmaFeatures property by the parserOptions property and add ... Due to change //# ->`` `// #...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
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.
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.