Declaratively specify rule option values

[mikesherov]

Instead of manually asserting in the configure function of a rule, we should be able to specify what values are accepted declaratively. This will also allow us to automate the creation of sample .jscsrc files. In order to do this, we need:

1. A way to set option values.
2. A way to verify provided values against use supplies values.
3. A way to automate error messages when a supplied value doesn't match.
4. A way to retrieve the possible values for a given rule.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[am11]

👍

@mikesherov, would we have to do meta-programming to achieve this? One way to go about it is by querying rules directory and strip the names to collect supported rules. But then we would have to look at some other place to find the possible/default values (would be nice if we are able to gather all possible values and enclose them in inline comment /**/ next to each rule's default value in the generated .jshintrc).

The switch name for this may be --build-config. :)

[mikesherov]

@am11 no need for meta programming, just a set of properties on each rule that defined its accepted / coerced values.

[am11]

Actually I was thinking about automating the elicitation process, so no extra work is performed when adding new rules. Or one common place where rules are defined and all adapters will look there for supported rules.

[am11]

I just realized that CoffeeScript has a similar switch: coffeelint --makeconfig > coffeelint.json. See http://www.coffeelint.org/#usage. Now we have a reference point as well. :)

[mrjoelkemp]

@mikesherov What if we only allow the creation of jscsrc files based on presets? Something like:

jscs -g jquery would create a .jscsrc that's a clone of the contents of presets/jquery.json.

Unless you're thinking of creating a cli that walks you through the creation of a jscsrc, I'm not seeing the value here that warrants the work of changing how we check for valid inputs.

[benjamine]

something like this would be nice: http://browsenpm.org/package.json

[markelog]

First and second is #895, consider it as sub-task to this issue

[elicwhite]

If we are considering auto generating doc blocks as well to be consistent with the specified options, how do we plan on handling good/bad examples? Seems unlikely that we'd be successful at choosing good options for those in code.