Metriche repository
- Star
- (8937 star)
- Metriche merge PR
- (Nessuna PR mergiata in 30 g)
Descrizione
Sorry if this is a duplicate, it seems like something that would have been brought up before but I've been looking for about half an hour without finding it.
The issue is that there is no documentation regarding the "vanilla" state of jshint. If you install jshint and run it on a lone file with no configuration, there's no way to know what errors and warnings you might get, and when you do get them, there's no way to know what options configure that error or warning or even if you can configure it.
Most of the actual errors (E*** messages) seem to be directly related to JS syntax errors. This is reasonable enough - most of them mean that the JS source simply will not run, so you should always see such errors and not be able to turn them off. (The exception seems to be the strict mode error E007, which is prescriptive - that is, not related to any JS syntax or runtime errors, just an opinion or potential bug. That should probably be a warning instead. Also unsure about E040 which seems to disallow case 1, 2:, which would also be prescriptive if it worked - how is it possible to trigger it when the whole case expression has already been consumed on L3746? E014 also does not seem to be triggerable anymore.)
However, there are many warnings (W*** messages) that are not JS syntax or runtime errors, but merely prescriptive warnings, and yet they are always on, cannot be configured, and are not documented anywhere. A few examples, none of them actual JS errors, are W001, W032, W041, W065, and W080.
The point here is not that they are bad warnings. They are mostly common sense and good warnings to have. So what I am not saying here is that they should necessarily have configuration options. It's understandable for jshint to simply take an opinionated stance on some things - it is a linter in the end and not just a syntax checker, and there are other tools to use if one wants no unconfigurable linting opinions. What I'm saying is that, ideally, all warnings that can be triggered would have clear documentation, and those with options affecting them would also link to those options' documentation, or simply include them inline. Here are some reasons why:
- As I mentioned to start out, there isn't any comprehensive information on what the "vanilla" state of jshint is. That is, if I run it on any given file with no configuration, what errors and warnings can it generate?
- Further information and examples. Many warnings have terse and obscure messages since they are intended for a space-limited standard output, but this can lead to confusion about what the problem is and ways to avoid it, especially if one is not experienced with Javascript and all of the terminology.
- Makes usage difficult for experts wanting to leverage jshint but disagreeing with one of the unconfigurable warnings. For instance, maybe someone wants to use
if (str == '')to guard a function parameter and knows exactly what it will do and which values will result in true. Sure they can disable W041 per file, but finding that number and how to disable it takes some time since it looks like any other warning and doesn't have any documentation. - Last but not least, it makes matters difficult for anyone making companion tools to jshint - for instance, an IDE plugin, an interactive GUI, a configuration converter, or a site like http://jslinterrors.com/. There's no comprehensive documentation on which warnings are on by default, off by default, or configurable, or what patterns they are triggered on, so any such effort is going to be mostly guess-and-check.
Even if that documentation was just a Markdown copy of https://github.com/jshint/jshint/blob/master/src/messages.js with a single example of a trigger for each warning and a list of any options affecting it, that would be a huge improvement. It would also be good to know what kind of error or warning they are: A potential bug in the source, or an error or warning related to jshint itself.