ESLint version

HEAD

What problem do you want to solve?

With flat config, we currently cannot apply eslint:recommended or eslint:all to a subsection of files. In eslintrc, we can do this:

module.exports = {
    overrides: [
        {
            files: ["src/foo/*.js"],
            extends: ["eslint:recommended"]
        }
    ]
};

What do you think is the correct solution?

Option 1: Core plugin

One option is that we could expose a "core plugin" at eslint/plugin that contains the rules, parsers, and special configs that ship with ESLint. That would end up looking like this:

import corePlugin from "eslint/plugin";

export default [
    {
        files: ["src/foo/*.js"],
        ...corePlugin.configs.recommended
    }
];

So both eslint:recommended and eslint:all would be exposed through configs, just like this was a standalone plugin.

Pros:

• Represents eslint:recommended and eslint:all as objects instead of strings.
• Brings these special configs into alignment with configs exposed in plugins, so there's just one way to include configs from outside of your project.
• We can eliminate the special "eslint:recommended" and "eslint:all" treatment (if we want).

Cons:

• Creates a dependency relationship between shareable configs/plugins and ESLint, where they will need to have at least a peerDependencies reference to ESLint, if not dependencies to ensure everything works correctly.

Option 2: Function configs

Another option is we could allow function configs that receive a context object with a reference to the special configs, such as:

export default function (context) {
    [
        {
            files: ["src/foo/*.js"],
            ...context.getConfig("eslint:recommended")
        }
    ];
}

So both eslint:recommended and eslint:all would be exposed through context.getConfig() (or some other function).

Pros:

• Represents eslint:recommended and eslint:all as objects instead of strings.
• Solves the problem of option 1 by ensuring that shared configs don't need a direct dependency relationship to ESLint.
• ConfigArray already supports function configs, it's just disabled right now.

Cons:

• Introducing function configs complicates sharing configs. Whereas right now we can assume that a shared config is either an object (you can use with the spread operator) or an array of objects (you can use map() to apply to different files and ignores), function configs hide their internals, and because they expect that context object, will be hard to manipulate and customize.

Option 3: External package

Yet another option is we could publish a separate package with just the special configs. If we end up externalizing all JavaScript-related functionality (as suggested in #16482), then a step in that direction would be to publish a @eslint/js package, which would make it a natural location for these special configs. This is what it would look like:

import js from "@eslint/js";

export default [
    {
        files: ["src/foo/*.js"],
        ...js.configs.recommended
    }
];

Pros:

• Represents eslint:recommended and eslint:all as objects instead of strings.
• Solves the problem of option 1 by ensuring that shared configs don't need a direct dependency relationship to ESLint.
• By publishing an out-of-band @eslint/js package, we would be free to update these configs as necessary and also start down the path of removing JS-specific functionality from the core.

Cons:

• Introduces another package to manage and release.
• Possible synchronicity issues between the eslint package and the @eslint/js package, although this could likely be mitigated by also moving rules into @eslint/js at some point.

Participation

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

Additional comments

There may be other options I haven't listed out, so feel free to suggest them.

This appears to be the one case that eslintrc supports and flat config doesn't, so figuring this out is important to get us past the beta stage.

I don't want to consider adding extends to flat config to solve this as it would introduce additional complexity into the config system that we were hoping to avoid with flat config.