Bug: [Flat config] Errors should indicate which config object contains error
[My apologies for not using the template to provide an executable MRE. Hopefully this problem is self-evident enough that's not needed]
Environment
$ npx eslint --env-info
Environment Info:
Node version: v20.16.0
npm version: v10.8.1
Local ESLint version: v9.10.0 (Currently used)
Global ESLint version: Not found
Operating System: darwin 23.5.0
Problem
As mentioned in the title, if a eslint.config.js file exports an array of configs with more than one item, diagnosing which config object has the error can be problematic.
Example
The config: eslint.config.js
// Note: Invalid plugins object structure in 3rd config object
export default [ {}, {}, { plugins: ['react'] }, {} ]
The error
$ eslint .
Oops! Something went wrong! :(
A config object has a "plugins" key defined as an array of strings.
Flat config requires "plugins" to be an object in this form:
{
plugins: {
react: pluginObject
}
}
NOTE: Log output fails to show which of the four config objects has the bad plugins key. This puts the user in the position of having to guess and/or use trial and error to track down which of the four config objects is the problem.
This becomes particularly problematic as the size and complexity of the array grows. For example, our (CodePen's) current config setup has a dozen different config objects:
export default [
js.configs.recommended,
...eslintTypescript.configs.recommended,
eslintImport.flatConfigs.recommended,
eslintJest.configs['flat/recommended'],
eslintPromise.configs['flat/recommended'],
eslintReact.configs.flat.recommended,
eslintReactHooksFlat,
eslintSonar.configs.recommended,
eslintUnicorn.configs.recommended,
// custom configs
codepenIgnores,
codepenGraphql,
codepenRailsGraphql
];
Solution (Proposed)
Option 1: include config index in error
At a minimum, including the index of the config object in the error message would be helpful. For example...
~~A config object~~ Config object at index 2 has a "plugins" key defined as an array of strings.
Option 2: support config#name property on config objects, and include in error
For example, with this config...
export default [
{ name: 'oneConfig' },
{ name: 'twoConfig' },
{ name: 'redConfig', plugins: ['react'] },
{ name: 'blueConfig' }
]
... the error might read:
~~A config object~~ "redConfig#plugins" key defined as an array of strings.
Thanks for the report. This isn't a bug, it's a feature request (everything is working as designed and you're asking to add something new).
We actually already have a system that wraps location information around some config errors. We just need to expand that to cover more types of errors.
Do you want to submit a pull request for this?
it's a feature request
Fair enough.
Do you want to submit a pull request for this?
"want to"? yes. "able to"? Not so much at the moment. I'll take a stab at it if I find some spare time, though.
Looks like @snitin315 has claimed it.