Tightening Jshint

Measuring and increasing number of jshint settings.

A typical software project goes through multiple phases and iterations. It starts as an idea, maybe involves some planning, then the development begins. The features are added, tests are created, users and stakeholders are consulted. If initial iteration is successful, more customers appear, asking for features, fixes, and integration with other software pieces.

The project is in the flux at first: things are being prototyped, tests (if they exists) are sparse; the main focus is on implementing the right functionality. Later, as first features are solidified, the developers need to worry about not breaking the as new things are added. Regression tests become necessary, and features are described more formally.


Jshint is an excellent sanity check tool for JavaScript. Initially, just a clone of Jslint, it quickly became the goto static analysis tool, catching misspelled variables, stray brackets and such.

Most projects I see use Jshint settings stored in a separate JSON file, usually called .jshintrc in the project's root folder. Multiple tools can load this file and run Jshint on the source code: editors, command line tools, grunt build tool. The latest version of jshint allows more than 60 static checks specified using .jshintrc.

At the project's start we might specify pretty lenient settings, planning to tighten the checks later. For example, since we might not agree on the types passed around, we might use truthy equality == to compare variables. Later we would switch to more robust triple equal === operator that does not perform type casting. So the jshint would start with:

"eqeqeq": false  // do not require ===, allow ==

and later start checking for more robust comparison

"eqeqeq": true  // require === for comparison


The project matures, but no one takes a second look at the Jshint settings file, tightening the screws! So the settings that are supposed to help us catch regressions are never switched on.


I wrote jshint-solid to measure and warn when the project's Jshint settings are too permissive. The warnings can be ignored at the early stages, but as you start releasing the software to customers, you might heed the warnings and start flipping more switches, progressively making decisions about software principles, allowed language features and environment variables.

The exact values set in .jshintrc file are not checked at this point, the fact that the team actually decided on an option is the important fact. Later I plan to look at the individual options to warn about bad software practices, for example to warn that the setting boss (tolerate assignments where comparisons would be expected) is set to true.

Installation and use

Requires nodejs. Install jshint-solid as the global command line tool.

npm install -g jshint-solid

Go inside the folder were .jshintrc is located and call

// shows results

You can pass .jshintrc path as first argument

jshint-solid /projects/foo/.jshintrc

The tool prints the percentage of all possible jshint settings specified inside the file:

// typical run
$ jshint-solid
jshint ./.jshintrc covers 14% of all possible settings
see all possible settings at

The exact coverage thresholds are up to the team. I suggest using very low number initially, but during the first "maturation" step, increase the threshold to 40-50%. Before releasing the software to external customers, you might want to tighten even more and set the majority of switches.

It is very simple to decide on most of the settings, even initially, Jshint has a lot of target environment settings, for example for a nodejs application one could easily set 12 options:

"browser"       : false,    // Web Browser (window, document, etc)
"couch"         : false,    // CouchDB
"devel"         : true,     // Development/debugging (alert, confirm, etc)
"dojo"          : false,    // Dojo Toolkit
"jquery"        : false,    // jQuery
"mootools"      : false,    // MooTools
"node"          : true,     // Node.js
"nonstandard"   : false,    // Widely adopted globals (escape, unescape, etc)
"prototypejs"   : false,    // Prototype and Scriptaculous
"rhino"         : false,    // Rhino
"worker"        : false,    // Web Workers
"wsh"           : false,    // Windows Scripting Host
"yui"           : false,    // Yahoo User Interface


Let me know if jshint-solid is useful by twitting @bahmutov. If you find a problem, please open an issue at github and it will be resolved.