Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug: [Flat config] Errors should indicate which config object contains error #18926

Open
broofa opened this issue Sep 19, 2024 · 3 comments
Open
Assignees
Labels
accepted There is consensus among the team that this change meets the criteria for inclusion enhancement This change enhances an existing feature of ESLint

Comments

@broofa
Copy link

broofa commented Sep 19, 2024

[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.

@broofa broofa added bug ESLint is working incorrectly repro:needed This issue should include a reproducible example labels Sep 19, 2024
@github-project-automation github-project-automation bot moved this to Needs Triage in Triage Sep 19, 2024
@nzakas nzakas added enhancement This change enhances an existing feature of ESLint accepted There is consensus among the team that this change meets the criteria for inclusion and removed bug ESLint is working incorrectly repro:needed This issue should include a reproducible example labels Sep 20, 2024
@nzakas nzakas moved this from Needs Triage to Ready to Implement in Triage Sep 20, 2024
@nzakas
Copy link
Member

nzakas commented Sep 20, 2024

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?

@snitin315 snitin315 self-assigned this Sep 20, 2024
@broofa
Copy link
Author

broofa commented Sep 20, 2024

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.

@nzakas
Copy link
Member

nzakas commented Sep 20, 2024

Looks like @snitin315 has claimed it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepted There is consensus among the team that this change meets the criteria for inclusion enhancement This change enhances an existing feature of ESLint
Projects
Status: Ready to Implement
Development

No branches or pull requests

3 participants