Restrict rules to a minimum parserOptions.ecmaVersion

Problem

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.

[platinumazure]

Hmm. Why it should be an option for parser, since it’s an option for eslint itself to filter out rules or whatever? If option wasn’t passed explicitly we can use the most common by default (ES6 for now?).

Well, at the present moment, ecmaVersion is specified under parserOptions in config. The whole parserOptions block is sent to the specified parser (or espree by default). Some parsers might not understand ecmaVersion. 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 same ecmaVersion 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:

if (context.parserOptions.ecmaVersion < 5) {
    context.report({
        node: node,
        message: "Cannot run rule on this file: ecmaVersion must be greater than 5"
    });
}

But even that still presupposes a particular parser configuration.

[platinumazure]

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.