Do not apply ES6+ specific rules in non ES6+ environements

I’m experimenting with eslint:all, and found that when relying on "ecmaVersion": 5 the ES6+ rules still get in, and force me to produce not syntactically correct output.

e.g. prefer-arrow-callback forces to use arrow functions, which cannot work in ES5.

It’ll be cleaner if rules dedicated for ES6+ syntax are simply not applied on files linted with "ecmaVersion": 5 option (and below). For now workaround is to manually disable rules that force ES6 syntax.

[platinumazure]

Additionally, it’s worth noting that eslint:all is very much a “use at your own risk” feature. It won’t work for everybody, and I would expect that people would need to do some per-rule configuration overrides when the default settings don’t or can’t work.

In your case, I would expect you would need to disable all of the ES6 rules for your codebase.

[not-an-aardvark]

It might be good to have that cleaned out. I was personally puzzled that ECMAScript version can be set in two different parts of configuration (env and parserOptions). Now you’re saying that there are cases when both are ignored.

The parserOptions config object is just a set of options that get passed to the parser. Parsers can do whatever they want with these options, including ignoring them. The default parser happens to have an ecmaVersion: 6 option that changes parsing semantics, but this isn’t the case for all parsers.

It’ll be way nicer if there’s one straightforward way to set this up, and if some eslint plugin doesn’t respect that, then it should be seen as a bug in a plugin (btw not everyone uses babel).

I agree that it’s important to make eslint easy to configure, but I don’t think limiting the functionality of parsers in the manner you’re suggesting is a good way to do this. One of the design goals of eslint is that everything is pluggable, and naturally, not all parsers will have the same configuration options as the default parser. Rules are generally intended to be runnable regardless of what parser produced their AST, so it wouldn’t make sense to couple the general logic for enabling rules with parser-specific syntax options.

It’s important to note that this is only a problem when using eslint:all. There is a reason all rules are off by default – among other things, not all rules are applicable to all projects. If you’re using eslint:all to get familiar with eslint’s capabilities, then that’s fine (and I’m glad it’s working well for that purpose), but it’s not what eslint’s configuration system is designed and optimized for.