ESLint version

HEAD

What problem do you want to solve?

While working on the Language Plugins RFC I discovered a bit of complexity related to languageOptions. Right now, languageOptions is managed and resolved inside of the ESLint core, allowing us to do stuff like this:

export default [
    {
        plugins: {
            "@": { 
                parsers: require("espree")
            }
        },
        languageOptions: {
            parser: "@/espree"
        }
    }
];

In order to make this work, the core resolves @/espree to the plugin.parsers.espree key. This works well now, but once we move languageOptions resolution out of the core, we'd need to mimick this behavior or else remove it.

What do you think is the correct solution?

I believe the correct solution is to remove the resolution of the languageOptions.parser key and enforce that languageOptions.parser always be an object. So we would end up with a default config looking more like this:

export default [
    {
        plugins: {
            "@": { /* core plugin */  }
        },
        languageOptions: {
            parser: require("espree")
        }
    }
];

I think that this change won't affect many users, if at all, considering the majority of ESLint users aren't using the default parser and the most popular parsers (typescript-eslint and Babel) are still distributed as individual objects rather than plugins. For people using Espree, this change will be completely transparent.

Complexities of supporting resolution

The other option, which I don't think is a good idea, is to allow languages to specify keys to be resolved from plugins. So for the @eslint/js package, we'd need a way to say "the parser key should be resolved to the plugin parsers key with the given name. While we could do that, that would also open the door for any language plugin to specify its own key inside of an ESLint plugin, and then we'd be at risk of naming collisions, essentially creating a global scope into which any plugin can reach.

Because parser is the only key inside of languageOptions that does this plugin resolution, it makes more sense to me to eliminate this as a special case.

Participation

• I am willing to submit a pull request for this change.

Additional comments

No response