You can clone with
HTTPS or Subversion.
The current use of true and false as option values seems to indicate deviation from the "norm", defined for most options as Douglas Crockford's historic opinion of how JS should be written. This really only makes sense if there is a defined norm; jshint seems to consider the eradication, or at least mutability, of such a concept its raison d'être.
In any case, the use of true and false is confusing, because for some options true dictates that some restriction is enforced, whereas for others it means that a restriction is not enforced.
Being able to explicitly specify, say, warn or allow as the option value would make it easier to remember how to configure jshint and to read configuration files and comment-embedded options.
/*jshint evil: allow, curly: allow, forin: warn */
would equate to
/*jshint evil: true, curly: false, forin: false */
I agree with that. I would even change/combine some options so that they accept three possible states: error, warn, skip. However, we need to make sure that all those changes are backwards compatible.
Marking the issue as accepted.
+1 to better option values,right now it is too confusing...
+1 also to different kinds of errors, it will allow IDEs to generate different error messages and we could even have a flag to only report errors, warnings or everything.
Issue #177 is also related.
I guess the comment "identifier string" (i.e. /*jshint) might have to be different so that older (including now-current) versions of jshint wouldn't spit out warnings/errors on currently invalid values. Maybe /*jshint-options? IIRC the parsing code ignores everything that doesn't match one of the comment identifiers followed by a space.
one problem is that we have too many different kinds of options... I could group them into 4 different groups so far (environments, allow, disallow and requirements), adding error, warn and skip wouldn't be enough to solve the ambiguity problem.
we can create a hash table to convert true/false into error or skip (based on the option type), so it would be backwards compatible and no need to create a new "identifier string".
JSLint made changes to the option values today
Yeah, as @I-ARE-RIO said, Crockford has just made a huge change in the options - all "enforcing" options became "relaxing" options... see this commit. What are your thoughts on this, @antonkovalyov? Should JSHint follow suit?
We can't do the same thing because, unlike Crockford, I don't want to break all setups that set those options in their source codes. I.e. if you had /*jslint newcap:true */ and assumed that it enforces constructor capitalization after the upgrade it will actually relax that rule which is not what you'd expect.
/*jslint newcap:true */
Also I like the proposition of "warn", "ignore" and "error" states instead of boolean true/false. That way we can actually preserve backwards compatibility by checking if the option is boolean (legacy) or a string (new system).
What do you think?
Yeah, I also thought that suddenly changing the API so that the options mean something completely opposite isn't very nice for the users... I found this when I ran JSLint and JSHint against my code and was surprised that JSLint reported so many errors.
Warn/ignore sounds like a very good solution to me. It's definitely more work on your side, but much more convenient for the users.
Ya, that change is on my priority list.
just to remember that "warn", "ignore", "error" won't work for environment variables (node, browser, devel, dojo, jquery, etc...) and we should keep boolean values for them.
And that one thing that may be weird is having something like: /*jshint eqeqeq:error */ - by first looking at it I would expect that if you use === it would be considered an error but in fact it considers == an error, so it still ambiguous.
/*jshint eqeqeq:error */
other options that would also be weird if used together with the proposed states:
I still think that the problem is on the properties names and not on the fact that it is using boolean values.
The fact that they are booleans prevents users from controlling whether a message should be simply a warning or a fatal error. I agree that names should be revisited as well.
What is the status of a possible options redesign? Is this still planned, or is something of this kind currently in progress, or have you given up? Have you decided in what direction should this go?
Yes, this is still planned. I just need more time on my hands.
+1 for this.
What if we create a wiki page to list possible names to the each property like:
It will be easier to pick the good ones later if we have a list with many options and if more people help coming up with the names...
Just need to enable wiki pages on the repository settings and create a description on the top of the file telling that it is only a proposal and the file is being edited by many people, no one should remove names, just add things to the list..
+1 And an updated list of options will be also really appreciated, as I can't find full list of options at all (jshint-node has an example of configuration with keys not listed on official homepage o_O)
What options are not on jshint.com?
"sub" : true, // Tolerate all forms of subscript notation besides dot notation e.g. `dict['key']` instead of `dict.key`.
"maxerr": 100, // Maximum error before stopping.
"indent": 2 // Specify indentation spacing
Docs for sub are in there (http://cl.ly/2U143H0H030M1R1Z342t), I missed maxerr and indent though—will fix. Thanks!
Ooops. And I missed sub ;)) Thanks :))
Closing in favor of jshint-next.
For anyone else who sees this and looks for jshint-next
I don't see this issue resolved in new jsHint... Was the decision reverted?