Join GitHub today
Changing our parser options/ecmaFeatures #4641
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
This proposal is not fully fleshed out, just looking to get some eyes on it.
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
parserOptions: ecmaVersion: 6 sourceType: "module" # if you want
I generally am in favor of this idea.
Here are a few things I'd like to discuss:
I think this proposal pretty well matches the usage patterns of a lot of users and certainly will work well for us at paypal.
Your direction is consistent with principle of analogy for learning and usability: make complexity of ESLint config similar to corresponding Babel config. The most recent standard ES version is what many beginning to intermediate devs will need.
Some extra effort to add certain future features or omit certain current features (in ESLint, or in Babel not transpile features after supported in browser or Node) for advanced dev ops is what Alan Cooper calls the principle of commensurate effort.
By the way, if the two projects ever find they are diverging in the amount of effort to configure for common use cases, it seems like a healthy response it too reach out and think it through together :)
I am not in this boat but something to think about: Based on
Maybe the answer is to not use ESLINT 2.x but then we dont back port bug fixes, so indirectly we are forcing people to move to 2.x.
Again just a thought, I am not opposed to what we are doing right now as I dont have this issue.
added a commit
Dec 11, 2015
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.