Informing user of faulty options about stylelint

[jeddy3]

There's a PR/discussion over at eslint about this (with links to two issues where it is discussed further). Perhaps we can take a page out of their book?

Looks like they're going for some sort of schema validation approach. Rules throwing errors seems to have been ruled at because:

Having rules validate options will significantly complicate rules implementation. Rules are currently responsible only for one thing, validating AST and reporting errors.

So, shall we park this issue for now and milestone it for way into the future?

[davidtheclark]

I'm in agreement. It will be nicer if we build this as a separate component of the architecture.

[MoOx]

It will be nicer if we build this as a separate component of the architecture.

+1. KISS for now :)

[davidtheclark]

Does anybody have an example of an application that they think does this really well?

[jeddy3]

The only one I know of is the aforementioned one in eslint (but that's probably due to that fact I don't have much experience with tooling). Looking back through their issues and pull requests, it looks like it was a heavily debated and discussed topic. So, one can only assume that what they have in place is well reasoned.

It seems they had to juggle a few things though, including how plugin rules and the rule-tester both work with the validator.

[davidtheclark]

Here's what I'm thinking might work:

• We create two util functions validatePrimaryOptions(result, ruleName, possible, actual) and validateSecondaryOptions(result, ruleName, schema, actual). Our rule signature includes two possible option-places: the primary options, which should always be a single value, and secondary options, which should always be an object. Maybe we blend those into a single function -- whatever turns out simplest. Either way, the idea would be that each plugin calls this for each of its options arguments.
• possible is an array of possibilities. Each possibility is either a value (e.g. "always") or a function that returns true to say that the actual value is acceptable (e.g. check if it's an integer or "tab" for indentation)
• schema is just an object whose keys correspond to secondary options and values are possible arrays.
• All the validate functions do is check whether the option is valid; and if not, attach a warning to result.

That's the simplest solution I can think of, though it may not be the best. Any thoughts?

[jeddy3]

Seems like a sensible approach to me :)

Is there something in there to check that *-no-* rules, which have no options, would attach a warning if any options are supplied e.g. is can validatePrimaryOptions accept something like null for possible instead of an array?

Or is overloading that function not the best approach, and instead we have a 3rd function called something like validateNoOptions?

[davidtheclark]

Sure, we could make the possibilities an empty array, so anything entered there comes up wrong.

For warning messages, I was just thinking Invalid option "x" for rule "y", e.g. Invalid option "alwars" for rule "block-opening-brace-space-before". Check documentation. That seem ok?

[jeddy3]

Invalid option "x" for rule "y"

Spot on :)