Bug: `FlatESLint` `getRulesMetaForResults` fails on anonymous files when option `cwd` is set

Environment

Node version: v18.10.0 npm version: v8.19.2 Local ESLint version: v8.25.0 (Currently used) Global ESLint version: Not found Operating System: darwin 21.6.0

What parser are you using?

Default (Espree)

What did you do?

Using FlatESLint, the method getRulesMetaForResults thows an error for certain values of the option cwd when passed a result of an anonymous file. This happens whenever cwd is set to a subdirectory of the current directory.

The following repro shows the problem.

import { join } from 'path';

const { default: { FlatESLint } } = await import('eslint/use-at-your-own-risk');

const cwd = join(process.cwd(), 'test'); // subdir 'test' doesn't need to exist for this repro.
const eslint = new FlatESLint({
    cwd,
    overrideConfig: { rules: { 'no-undef': 'warn' } },
    overrideConfigFile: true,
});
const results = await eslint.lintText('foo()');
eslint.getRulesMetaForResults(results); // throws TypeError

What did you expect to happen?

Calling getRulesMetaForResults with the result of an anonymous file should not throw an error, regardless of the engine’s cwd.

What actually happened?

The above repro fails with an error like this:

.../node_modules/eslint/lib/config/flat-config-helpers.js:54
    const plugin = config.plugins && config.plugins[pluginName];
                          ^

TypeError: Cannot read properties of undefined (reading 'plugins')
    at getRuleFromConfig (.../node_modules/eslint/lib/config/flat-config-helpers.js:54:27)
    at FlatESLint.getRulesMetaForResults (.../node_modules/eslint/lib/eslint/flat-eslint.js:703:30)
    at file://.../example.mjs:12:8

Participation

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

Additional comments

What strikes me in the implementation are the different values used to call configs.getConfig in the case of an anonymous file: lintText calls configs.getConfig with a full path like ${cwd}/__placeholder__.js

https://github.com/eslint/eslint/blob/173e82040895ad53b2d9940bfb3fb67a0478f00b/lib/eslint/flat-eslint.js#L956

whereas getRulesMetaForResults ends up calling configs.getConfig("__placeholder__.js")

https://github.com/eslint/eslint/blob/173e82040895ad53b2d9940bfb3fb67a0478f00b/lib/eslint/flat-eslint.js#L689-L699

Then it finds no config and it fails.

Another issue related to this is the unhelpful message of the TypeError. When getRulesMetaForResults finds no matching config, it could simply tell the user that the results were not created from the current instance of ESLint (not the case here, but still). The error message is already there, but it is currently only used in a more limited edge case:

https://github.com/eslint/eslint/blob/173e82040895ad53b2d9940bfb3fb67a0478f00b/lib/eslint/flat-eslint.js#L684

[mdjermanovic]

getConfig() can be costly, but at that point config for the filePath should have already been calculated (because the file was linted) and cached. so it will just return the cached config object. After finding a message that has ruleId, we could check if config is not an object and throw a better error message, as it is unexpected that ignored files have messages from rules.

[mdjermanovic]

Shall I extend #16409 or create a new PR?

As #16409 is already being reviewed, it might be better to create a new PR that fixes the two problems from this issue (handling the "<text>" file path, and improving the error message when file doesn’t have a config).