Restrict rules to a minimum parserOptions.ecmaVersion
See original GitHub issueProblem
Right now half of my projects are written in ES6. Half in ES5. I have a shareable config I re-use between my projects. The problem I have is that I have to create separate sharable configs for my ES5/ES6 projects. Because rules such as prefer-template
or prefer-spread
give warnings regardless of my configured parserOptions.ecmaVersion
.
Solution
A minimum ecmaVersion configurable per rule.
module.exports = {
meta: {
ecmaVersion: 6
}
}
Note: I know you can create multiple files in a sharable configs and extend those fitting the specific project. This is how I solve this right now.
I’d like to know if this would be a good idea or not.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:1
- Comments:6 (6 by maintainers)
Top Results From Across the Web
Configuring ESLint - ESLint - Pluggable JavaScript Linter
A pluggable and configurable linter tool for identifying and reporting on patterns in JavaScript. Maintain your code quality with ease.
Read more >Understanding ESLint Rules
Rules are the fundamental building block for ESLint. Every ESLint configuration is a collection of rules and how strictly those rules are ...
Read more >Configuring ESLint - GitHub Pages
The goal is to allow TypeScript files to be parsed by ESLint (though not necessarily pass all ESLint rules). Note when using a...
Read more >next.js Setting up ESLint for NextJs
Minimal eslint example. The setup contains: package.json { "name": "with-eslint", "version" ...
Read more >How to create a custom ESLint configuration and ...
Let's consider a rule where we restrict the use of color literals within Javascript files(or React components) and let's name the rule as:...
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
Well, at the present moment,
ecmaVersion
is specified underparserOptions
in config. The wholeparserOptions
block is sent to the specified parser (or espree by default). Some parsers might not understandecmaVersion
. And I don’t think it’s a good idea to overload the responsibility of that particular parser option, because then the configuration design violates the Single Responsibility Principle and could result in users writing in with issues due to unexpected rule ignores (or the parser not liking their options, or…).I (personally, not speaking for the team) could get behind some
ecmaVersion
rule constraint, as long as it’s not the sameecmaVersion
as what is used in parser options. But even then, it would probably need a different nomenclature to reduce chance of confusion.As it is, it’s possible to warn within rules for this:
But even that still presupposes a particular parser configuration.
Just to add, glob-based configuration (if that ever gets implemented) could make it easier to maintain one configuration that allows some files to use es6 rules.