Inform user of valid enum values when an invalid rule config value is given

[ejfrancis]

The version of ESLint you are using.

2.11.1

The problem you want to solve.

It would be helpful to the user to list out the valid rule configuration enum values when an invalid value is given.

For example, when setting a configuration for a rule in an .eslintrc.json file, say for the "quotes" rule like below

{
  "rules": {
    "quotes": [2, "backtick"]
  }
}

If an invalid config value is given (i.e. "backticks" instead of "backtick") the error output written to stdout looks like this

Error: /home/user/xyz/.eslintrc.json:
    Configuration for rule "quotes" is invalid:
    Value "backticks" must be an enum value.

At that point the user has to look up the documentation for the rule to see that the valid options are "double", "single" or "backtick".

Your take on the correct solution to problem.

It would be helpful if the error logged something like this:

Error: /home/user/xyz/.eslintrc.json:
    Configuration for rule "quotes" is invalid:
    Value "backticks" must be a value of enum ["double", "single", "backtick"] .

from the rule's exports.metcha.schema.enum. Perhaps a fuzzy string match could be used to make a suggestion along the lines of `

Value "backticks" must be a value of enum ["double", "single", "backtick"]. Did you mean "backtick"?

using a package like string-score

[platinumazure]

👍 from me. Every little bit helps.

[mysticatea]

I'm not familiar with the validation logic, but I guess the message was generated by is-my-json-valid package.

[btmills]

@mysticatea is correct that the schema validation error messages are coming directly from is-my-json-valid. I think it's a great idea though, would you mind filling an issue over there @ejfrancis?

[ejfrancis]

@btmills no problem, I just filed an issue over in the is-my-json-valid repo

[kaicataldo]

I'm closing this issues because it looks like consensus couldn't be reached. While we wish we could accommodate all requests, we have limited resources and do need to prioritize. We've found that issues failing to reach consensus after 21 days tend to never reach consensus, and as a team have decided to close such issues. This doesn't mean the idea isn't interesting or valuable, only that it's not something the team can commit to at the moment.