Change Request: Provide config key when config validation fails

[martypdx]

ESLint version

8.55.0

What problem do you want to solve?

When the config file fails validation there is very little information to go on. In connection with #17959, using "error" for reportUnusedDisableDirectives causes the load to fail with error below which has no information on which config caused the error or call stack entry with line numbers.

% npm run lint -- src/www/main.js

> vite-poc@0.0.0 lint
> eslint src/www/main.js


Oops! Something went wrong! :(

ESLint: 8.55.0

TypeError: Expected a Boolean.
    at Object.boolean [as validate] (/Users/marty/gitmllc/vite-poc/node_modules/@humanwhocodes/object-schema/src/validation-strategy.js:36:19)
    at ObjectSchema.validate (/Users/marty/gitmllc/vite-poc/node_modules/@humanwhocodes/object-schema/src/object-schema.js:285:35)
    at Object.validate (/Users/marty/gitmllc/vite-poc/node_modules/@humanwhocodes/object-schema/src/object-schema.js:180:32)
    at ObjectSchema.validate (/Users/marty/gitmllc/vite-poc/node_modules/@humanwhocodes/object-schema/src/object-schema.js:285:35)
    at /Users/marty/gitmllc/vite-poc/node_modules/@humanwhocodes/object-schema/src/object-schema.js:239:18
    at Array.reduce (<anonymous>)
    at ObjectSchema.merge (/Users/marty/gitmllc/vite-poc/node_modules/@humanwhocodes/object-schema/src/object-schema.js:237:24)
    at /Users/marty/gitmllc/vite-poc/node_modules/@humanwhocodes/config-array/api.js:966:42
    at Array.reduce (<anonymous>)
    at FlatConfigArray.getConfig (/Users/marty/gitmllc/vite-poc/node_modules/@humanwhocodes/config-array/api.js:965:39)

What do you think is the correct solution?

Report:

• the configuration setting that failed validation
• the found value for the setting that failed validation
• line number would be nice

Participation

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

Additional comments

Is there a type definition for new config file? I could see implementing this as type validation as well.

[martypdx]

I upgraded to 8.56 and the the new message about the failed value is 🤩

TypeError: Expected one of: "error", "warn", "off", 0, 1, 2, or a boolean.

Will there be more additions or changes to the validation errors?

Are there plans for a type def file for the eslint.config.js?

[bmish]

I do agree we need to at least indicate what property is involved.

[bmish]

Why was this closed?

[fasttime]

I also think that it would be good to include the name of the option in the error message. Reopening to get more feedback from the team @eslint/eslint-team.

[martypdx]

I waffled on it and closed because it seemed like the messages were improving and maybe already on the roadmap. But agree if opening is the thing to do to keep on the radar.

[nzakas]

@martypdx that's very strange. The flat config does typically tell you not just the key but the path to the key when there's a validation error. Can you create a Stackblitz that reproduces the issue you're seeing? I'd like to see it in action to understand what is happening here because this is unexpected.

[martypdx]

@nzakas here is a Stackblitz using these dep versions:

  "dependencies": {
    "@eslint/js": "^8.56.0",
    "eslint": "^8.56.0",
    "globals": "^13.24.0"
  }

If you run npm run lint from the terminal, you get details about the value, but no property info or info that a failed config is the issue.

This is same error you would see in OUTPUT ESlint tab of VSCode console

[nzakas]

Awesome ,thanks so much. I'll take a look.

[nzakas]

I was able to reproduce this locally. Interestingly, the unit tests are passing with key information, so somehow we are skipping over the logic that adds the key information to the message in this case.

[nzakas]

Okay, so it turns out the error is being produced with the key information, but our error reporting functionality is swallowing all of the details.

[nzakas]

This was actually caused by a change I made to object-schema. This was apparently a little too clever because it was interfering with the normal processing of errors, including modifying the stack as it went.