JSHint is a program that flags suspicious usage in programs written in JavaScript. The core project consists of a library itself as well as a CLI program distributed as a Node module.
More docs: List of all JSHint options · Command-line Interface · API · Writing your own reporter · FAQ
First, check out the installation instructions for details on how to install JSHint in your preferred environment. Both the command line executable and the JavaScript API offer unique ways to configure JSHint's behaviour. The most common usages are:
Regardless of your preferred environment, you can control JSHint's behavior through specifying any number of linting options. In addition, JSHint will honor any directives declared within the input source code--see the section on in-line directives for more information.
JSHint comes with a default set of warnings but it was designed to be very
configurable. There are three main ways to configure your copy of JSHint:
you can either specify the configuration file manually via the --config flag,
use a special file .jshintrc or put your config into your projects package.json
file under the jshintConfig property. In case of .jshintrc, JSHint will start
looking for this file in the same directory as the file that's being linted.
If not found, it will move one level up the directory tree all the way up to
the filesystem root. (Note that if the input comes from stdin, JSHint doesn't
attempt to find a configuration file)
This setup allows you to have different configuration files per project. Place your file into the project root directory and, as long as you run JSHint from anywhere within your project directory tree, the same configuration file will be used.
Configuration file is a simple JSON file that specifies which JSHint options
to turn on or off. For example, the following file will enable warnings about
undefined and unused variables and tell JSHint about a global variable named
MY_GLOBAL.
{
"undef": true,
"unused": true,
"globals": {
"MY_GLOBAL": true
}
}In addition to using configuration files you can configure JSHint from within your
files using special comments. These comments start with a label such as
jshint or globals (complete list below) and are followed by a
comma-separated list of values. For example, the following snippet will enable
warnings about undefined and unused variables and tell JSHint about a global
variable named MY_GLOBAL.
/* jshint undef: true, unused: true */
/* globals MY_GLOBAL */You can use both multi- and single-line comments to configure JSHint. These comments are function scoped meaning that if you put them inside a function they will affect only this function's code.
Here's a list of configuration directives supported by JSHint:
A directive for setting JSHint options.
/* jshint strict: true */A directive for setting JSHint-compatible JSLint options.
/* jslint vars: true */A directive for telling JSHint about global variables that are defined
elsewhere. If value is false (default), JSHint will consider that variable
as read-only. Affects the undef option.
/* globals MY_LIB: false */You can also blacklist certain global variables to make sure they are not used anywhere in the current file.
/* globals -BAD_LIB */A directive for telling JSHint about global variables that are defined in the
current file but used elsewhere. Affects the unused option.
/* exported EXPORTED_LIB */A directive for telling JSHint about all properties you intend to use. This directive is deprecated.
A directive for telling JSHint to ignore a block of code.
// Code here will be linted with JSHint.
/* jshint ignore:start */
// Code here will be ignored by JSHint.
/* jshint ignore:end */All code in between ignore:start and ignore:end won't be passed to JSHint
so you can use any language extension such as Facebook React.
Additionally, you can ignore a single line with a trailing comment:
ignoreThis(); // jshint ignore:lineMost often, when you need to tune JSHint to your own taste, all you need to do is to find an appropriate option. Trying to figure out how JSHint options work can be confusing and frustrating (and we're working on fixing that!) so please read the following couple of paragraphs carefully.
JSHint has two types of options: enforcing and relaxing. The former are used to make JSHint more strict while the latter are used to suppress some warnings. Take the following code as an example:
function main(a, b) {
return a == null;
}This code will produce the following warning when run with default JSHint options:
line 2, col 14, Use '===' to compare with 'null'.Let's say that you know what you're doing and want to disable the produced
warning but, in the same time, you're curious whether you have any variables
that were defined but never used. What you need to do, in this case, is to
enable two options: one relaxing that will suppress the === null warning and
one enforcing that will enable checks for unused variables. In your case these
options are unused and eqnull.
/*jshint unused:true, eqnull:true */
function main(a, b) {
return a == null;
}After that, JSHint will produce the following warning while linting this example code:
demo.js: line 2, col 14, 'main' is defined but never used.
demo.js: line 2, col 19, 'b' is defined but never used.Sometimes JSHint doesn't have an appropriate option that disables some
particular warning. In this case you can use jshint directive to disable
warnings by their code. Let's say that you have a file that was created by
combining multiple different files into one:
"use strict";
/* ... */
// From another file
function b() {
"use strict";
/* ... */
}This code will trigger a warning about an unnecessary directive in function b.
JSHint sees that there's already a global "use strict" directive and informs you
that all other directives are redundant. But you don't want to strip out these
directives since the file was auto-generated. The solution is to run JSHint
with a flag --verbose and note the warning code (W034 in this case):
$ jshint --verbose myfile.js
myfile.js: line 6, col 3, Unnecessary directive "use strict". (W034)Then, to hide this warning, just add the following snippet to your file:
/* jshint -W034 */A couple things to note:
W), it doesn't work
with errors (code starts with E).To re-enable a warning that has been disabled with the above snippet you can use:
/* jshint +W034 */This is especially useful when you have code which causes a warning but that you know is safe in the context. In these cases you can disable the warning as above and then re-enable the warning afterwards:
var y = Object.create(null);
// ...
/*jshint -W089 */
for (var prop in y) {
// ...
}
/*jshint +W089 */This page contains a list of all options supported by JSHint.
By default JSHint warns when you omit break or return statements within
switch statements:
switch (cond) {
case "one":
doSomething(); // JSHint will warn about missing 'break' here.
case "two":
doSomethingElse();
}If you really know what you're doing you can tell JSHint that you intended the
case block to fall through by adding a /* falls through */ comment:
switch (cond) {
case "one":
doSomething();
/* falls through */
case "two":
doSomethingElse();
}