Feature request: improve how configurations may be extended/loaded from the command line

The version of ESLint you are using. 7.24.0

The problem you want to solve.

I would like to “extend” rules by another set of rules contained in a “shareable configs” (inside a dependent package - https://eslint.org/docs/developer-guide/shareable-configs) from the commandline, like it is possible via package.json:

"eslintConfig": {
        "extends": "plugin:@scope/eslint-plugin/require-types"
}

This way it would be possible to have a set of standard rules when using eslint via editor (eg. VSCode), and use extended rules only on purpose directly from command line or through a package.json script.

Other ways to achieve this don’t seem to work:

• use “-c”- this needs a “real” file, which “@scope\eslint-config\require-types” is not In case of a single package, “node_modules/@scope/eslint-config/require-types” would work, but not in a workspace. There I would need to include several “…”, which is inflexible and doesn’t work at all for packages that shall be used inside as well as outside a workspace

• use “–plugin” respects the package (“@scope\eslint-config”), but there appears to be no way for naming the config to be used

[mdjermanovic]

For the context, this feature was supported since ESLint v1.2.0 (https://github.com/eslint/eslint/pull/3063) but then removed in ESLint v6.0.0 (https://github.com/eslint/eslint/pull/11388).

Per this change it looks like the feature was intentionally removed, though I can’t find a mention of it in https://github.com/eslint/rfcs/pull/7.

[mdjermanovic]

It does work as it seems, but it defeats the purpose of the shared config if every project needs “additional-config.js”.

Yes, if the expectation is that a config package can be used instead of a config file, but the shareable configs feature was not designed for that use case.

https://eslint.org/docs/developer-guide/shareable-configs#using-a-shareable-config

Shareable configs are designed to work with the extends feature of .eslintrc files

So, I think that the lack of CLI options was not an oversight.

---

This is an interesting feature request, but I’m not sure if we can really evaluate it before implementing the new flat config system. Otherwise, we could end up with a solution that works with eslintrc logic (which will be deprecated at some point), but cannot apply to the new config system.