Bug: can't run a single ESLint rule in CLI after migrating to flat config

[JavaScriptBach]

Environment

Node version: 20.12.2
npm version: 10.5.0
Local ESLint version: 8.57.0
Global ESLint version: 8.57.0
Operating System: Ubuntu 22

What parser are you using?

@typescript-eslint/parser

What did you do?

I have a pre-commit script that uses the CLI to run a subset of ESLint rules on commit. A minimal version of the command I'm running:

npx eslint --no-eslintrc \
    --parser '@typescript-eslint/parser' \
    --plugin 'import' \
    --plugin 'unused-imports' \
    --rule 'unused-imports/no-unused-imports: [error]' \
    --rule 'import/order: [error, {alphabetize: {order: asc, caseInsensitive: true}}]' \
    --fix \
    $IMPORT_FILES

After migrating to flat config, this command fails and tells me to switch to --no-config-lookup instead of --no-eslintrc. When I make the change, it still fails with "File ignored because of a matching ignore pattern.", likely because of #18263.

The workaround I'm using in the meantime is to prepend the old command with ESLINT_USE_FLAT_CONFIG=false.

What did you expect to happen?

After switching to --no-config-lookup, the command continues to work.

What actually happened?

  0:0  warning  File ignored because of a matching ignore pattern. Use "--no-ignore" to disable file ignore settings or use "--no-warn-ignored" to suppress this warning

✖ 1 problem (0 errors, 1 warning)

Link to Minimal Reproducible Example

See above

Participation

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

Additional comments

No response

[mdjermanovic]

Hi @JavaScriptBach, thanks for the issue!

Can you please provide a minimal reproducible example?

it still fails with "File ignored because of a matching ignore pattern.", likely because of #18263.

Yes, this message can appear for various reasons (not only because of a matching ignore pattern; we're working on the fix in eslint/rewrite#7), but without a reproducible example we can't know exactly what's causing this in the case you provided.

[JavaScriptBach]

@mdjermanovic here is a repro:

1. Create an empty file named eslint.config.js
2. Install eslint@8.57.0, eslint-plugin-import@2.29.1, and @typescript-eslint/parser@7.5.0
3. Create this test.ts file:

// test.ts
import b from "b";
import a from "a";

4. Run npx eslint --no-config-lookup --parser '@typescript-eslint/parser' --plugin 'import' --rule 'import/order: [error, {alphabetize: {order: asc}}]' --fix test.ts

[mdjermanovic]

Thanks for the info. I can reproduce this with the latest ESLint v9.3.0 too.

Here's what happens:

ESLint by default lints only .js, .mjs, and .cjs files. Other files can be linted only if there's a matching pattern in the config file. But with --no-config-lookup, there's no config file, so it's not possible to lint any other file extensions, like .ts.

To support linting any files with --no-config-lookup, it seems we'd need to reintroduce something like --ext?

@eslint/eslint-tsc thoughts about this use case?

Currently available workaround is to add another config file with just file patterns, and use that file with --config instead of using --no-config-lookup:

// eslint.pre-commit.js
export default [{
    files: ["**/*.ts"]
}];

npx eslint --config eslint.pre-commit.js --parser '@typescript-eslint/parser' --plugin 'import' --rule 'import/order: [error, {alphabetize: {order: asc}}]' --fix test.ts

[nzakas]

I think adding a config file is the right way to go here.

Trying to add back in --ext brings with it a lot of complexity as to how it should interact with the other CLI commands like --rule.

[mdjermanovic]

My opinion is neutral because the mentioned config file solution already covers this use case. Furthermore, with a config file, you could specify plugins, rules, and parser in it so you wouldn't need --plugin, --rule, and --parser but just run npx eslint --config eslint.pre-commit.js.

But if we do decide to add a CLI option for this use case, it could be a CLI-only feature that just adds a config object with the files key only (e.g., { files: ["**/*.ts"] } to overrideConfig array that CLI passes to API.

[fasttime]

I'd also argue that for this case, adding a config file like eslint.pre-commit.js seems a more suitable solution than introducing a new CLI flag. A config file also has the advantage that part of the settings could be shared with other ESLint configs in the project, which seems desirable given the problem description provided by the @JavaScriptBach.

I wouldn't be oppose though to add a new option (like --ext or another mechanism) to ensure that files specified in the CLI are actually matched, if other users were asking for this feature.

[JavaScriptBach]

I agree that using a pre commit config is the correct solution here, and it's now possible thanks to flat config. Thank you all for implementing it!