Right now, extending plugin:node/recommended is "half smart". By that, I mean that it does a bunch of stuff besides just adding rules, but some of those things are a little blunt:
It sets parserOptions.ecmaVersion to 2019, which will overwrite ESLint 8's feature of env settings being able to set a default ecmaVersion. In my real-world case, I set env.es2020 = true, which will automatically set parserOptions.ecmaVersion to 11 (aliased as 2020). eslint-plugin-node downgrades my ecmaVersion.
It also adds globals. But, setting ESLint's env.node = true also adds globals. I don't know what the overlap is or whether it's redundant.
A simple "fix" to these issues would be to have a "dumb" config that is just the rules used by "plugin:node/recommended" and would require us to manually do the other stuff, like adding to the plugins array.
I know that the plugin can use package.json's engines field for the no-unsupported-features rules. Perhaps it could use it for setting the parserOptions.ecmaVersion as well?
Right now, extending
plugin:node/recommended
is "half smart". By that, I mean that it does a bunch of stuff besides just adding rules, but some of those things are a little blunt:env
settings being able to set a default ecmaVersion. In my real-world case, I setenv.es2020 = true
, which will automatically setparserOptions.ecmaVersion
to 11 (aliased as 2020). eslint-plugin-node downgrades my ecmaVersion.env.node = true
also adds globals. I don't know what the overlap is or whether it's redundant.A simple "fix" to these issues would be to have a "dumb" config that is just the rules used by "plugin:node/recommended" and would require us to manually do the other stuff, like adding to the
plugins
array.I know that the plugin can use package.json's
engines
field for the no-unsupported-features rules. Perhaps it could use it for setting theparserOptions.ecmaVersion
as well?