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

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

Open
ejfrancis opened this issue Aug 6, 2016 · 2 comments

Comments

@ejfrancis
Copy link

ejfrancis commented Aug 6, 2016

(copied from eslint/eslint#6390 as this is a result of eslint using this package)

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 a json schema requires a value of enum ["double", "single", "backtick"], if an invalid config value is given (i.e. "backticks" instead of "backtick") the error output written to stdout looks like this

    Value "backticks" must be an enum value.

At that point the user has to look up the definition of the enum to see the valid values.

Your take on the correct solution to problem.

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

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

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

@dmwelch
Copy link

dmwelch commented Jun 27, 2017

IMO this should be an optional behavior, if implemented at all, as many services may not want to broadcast their available enums to every user (e.g. "security through obscurity", enum values that are available based on user's permissions, etc.).

This problem can and should be solved with good user documentation instead. Typos for enum values are easy enough to debug, albeit frustrating. 😉

@LinusU
Copy link
Collaborator

LinusU commented Jul 6, 2017

I think that this is a good addition, security through obscurity is a huge antipattern but if there is valid concerns we could make it a breaking change...

PR welcome

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants