The easiest way to use JSHint is to install it as a Node program. To do so, simply run the following command in your terminal (flag -g installs JSHint globally on your system, omit it if you want to install JSHint in the current working directory):
$ npm install jshint -g
After you’ve done that you should be able to use the jshint program. The simplest use case would be linting a single file or all JavaScript files in a directory:
$ jshint myfile.js
myfile.js: line 10, col 39, Octal literals are not allowed in strict mode.
1 error
JSHint comes with a default set of warnings but it was designed to be very configurable. There are two main ways to configure your copy of JSHint before: you can either specify the configuration file manually via the --config flag or use a special file .jshintrc. JSHint will look for this file in the current working directory and, if not found, will move one level up the directory tree all the way up to the filesystem root.
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": false }
}
Other configuration flags supported by JSHint:
--reporter Allows you to modify JSHint’s output by replacing its default output function with your own implementation.
$ jshint --reporter=myreporter.js myfile.js
This flag also supports two pre-defined reporters: jslint, to make output compatible with JSLint, and checkstyle, to make output compatible with CheckStyle XML.
$ jshint --reporter=checkstyle myfile.js
<?xml version="1.0" encoding="utf-8"?>
<checkstyle version="4.3">
<file name="myfile.js">
<error line="10" column="39" severity="error"
message="Octal literals are not allowed in strict mode."/>
</file>
</checkstyle>
See also: Writing your own JSHint reporter.
--verbose Adds message codes to the JSHint output.
--show-non-errors Shows additional data generated by JSHint.
$ jshint --show-non-errors myfile.js
myfile.js: line 10, col 39, Octal literals are not allowed in strict mode.
1 error
myfile.js:
Unused variables:
foo, bar
--extra-ext Allows you to specify additional file extensions to check (default is .js).
--help Shows a nice little help message similar to what you’re reading right now.
--version Shows the installed version of JSHint.
JSHint also has a Rhino build which you can download here.
$ rhino jshint-rhino.js myfile.js
Note that Rhino version doesn’t support flags described above. It is, actually, pretty basic.
If you want JSHint to skip some files you can list them in a file named .jshintignore. For example:
legacy.js
somelib/**
otherlib/*.js
The CLI JSHint module exposes a public method gather that you can use to hook up into the file resolution logic. This is useful if you want to change how JSHint gathers files for linting. Do this only if you really know what you’re doing.
#!/usr/bin/env node
var cli = require("./src/cli/cli.js");
cli.gather = function (opts) {
// Your own file gathering logic.
// For description of 'opts' see src/cli/cli.js:gather
};
cli.interpret(process.argv);
You can also use JSHint in your projects as a JavaScript library. You can either install it as a Node module and include with require or download our web bundle which exposes a global JSHINT function.
// With Node
var JSHINT = require("jshint").JSHINT;
JSHINT is a function that takes three formal parameters and returns a boolean:
var success = JSHINT(source, options, globals);
The first parameter is either a string or an array of strings. If it is a string, it will be split on ‘\n’ or ‘\r’. If it is an array of strings, it is assumed that each string represents one line. The source can be JavaScript or JSON.
The second parameter is an optional object of options which control the operation of JSHINT. Most of the options are booleans: They are all optional and have a default value of false.
The third parameter is an object of global variables, with keys as names and a boolean value to determine if they are assignable.
If your input passes JSHint tests, the function will return true. Otherwise, it will return false. In that case, you can use JSHINT.errors to retrieve the errors or request a complete report by calling the JSHINT.data() method.
In addition to the --config flag and .jshintrc file you can configure JSHint from within your files using special comments. These comments start either with jshint or global and are followed by a comma-separated list of value. 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 */
/* global 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.
| jshint | A directive for setting JSHint options. |
| jslint | A directive for setting JSHint-compatible JSLint options. |
| globals | A directive for telling JSHint about global variables that are defined
elsewhere. If value is
You can also blacklist certain global variables to make sure they are not used anywhere in the current file. |
| exported | A directive for telling JSHint about global variables that are defined in the
current file but used elsewhere. Use it together with the |
| members | A directive for telling JSHint about all properties you intend to use. This directive is deprecated. |
Most 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 */
| bitwise | This option prohibits the use of bitwise operators such as |
| camelcase | This option allows you to force all variable names to use either camelCase style or UPPER_CASE with underscores. |
| curly | This option requires you to always put curly braces around blocks in loops and conditionals. JavaScript allows you to omit curly braces when the block consists of only one statement, for example:
However, in some circumstances, it can lead to bugs (you'd think that |
| eqeqeq | This options prohibits the use of |
| es3 | This option tells JSHint that your code needs to adhere to ECMAScript 3 specification. Use this option if you need your program to be executable in older browsers—such as Internet Explorer 6/7/8—and other legacy JavaScript environments. |
| forin | This option requires all
For more in-depth understanding of |
| immed | This option prohibits the use of immediate function invocations without wrapping them in parentheses. Wrapping parentheses assists readers of your code in understanding that the expression is the result of a function, and not the function itself. |
| indent | This option enforces specific tab width for your code. For example, the following code will trigger a warning on line 4: |
| latedef | This option prohibits the use of a variable before it was defined. JavaScript has function scope only and, in addition to that, all variables are always moved—or hoisted— to the top of the function. This behavior can lead to some very nasty bugs and that's why it is safer to always use variable only after they have been explicitly defined. For more in-depth understanding of scoping and hoisting in JavaScript, read JavaScript Scoping and Hoisting by Ben Cherry. |
| newcap | This option requires you to capitalize names of constructor functions.
Capitalizing functions that are intended to be used with Not doing so won't break your code in any browsers or environments but it will
be a bit harder to figure out—by reading the code—if the function was supposed
to be used with or without new. And this is important because when the function
that was intended to be used with |
| noarg | This option prohibits the use of |
| noempty | This option warns when you have an empty block in your code. JSLint was originally warning for all empty blocks and we simply made it optional. There were no studies reporting that empty blocks in JavaScript break your code in any way. |
| nonew | This option prohibits the use of constructor functions for side-effects. Some people like to call constructor functions without assigning its result to any variable:
There is no advantage in this approach over simply calling |
| plusplus | This option prohibits the use of unary increment and decrement operators.
Some people think that |
| quotmark | This option enforces the consistency of quotation marks used throughout your
code. It accepts three values: |
| undef | This option prohibits the use of explicitly undeclared variables. This option is very useful for spotting leaking and mistyped variables.
If your variable is defined in another file, you can use |
| unused | This option warns when you define and never use your variables. It is very
useful for general code cleanup, especially when used in addition to
In addition to that, this option will warn you about unused global variables
declared via This can be set to "vars" to only check for variables, not function parameters, or "strict" to check all variables and parameters. The default (true) behavior is to allow unused parameters that are followed by a used parameter. |
| strict | This option requires all functions to run in ECMAScript 5's strict mode. Strict mode is a way to opt in to a restricted variant of JavaScript. Strict mode eliminates some JavaScript pitfalls that didn't cause errors by changing them to produce errors. It also fixes mistakes that made it difficult for the JavaScript engines to perform certain optimizations. Note: This option enables strict mode for function scope only. It prohibits the global scoped strict mode because it might break third-party widgets on your page. If you really want to use global strict mode, see the globalstrict option. |
| trailing | This option makes it an error to leave a trailing whitespace in your code. Trailing whitespaces can be source of nasty bugs with multi-line strings in JavaScript: |
| maxparams | This option lets you set the max number of formal parameters allowed per function: |
| maxdepth | This option lets you control how nested do you want your blocks to be: |
| maxstatements | This option lets you set the max number of statements allowed per function: |
| maxcomplexity | This option lets you control cyclomatic complexity throughout your code. Cyclomatic complexity measures the number of linearly independent paths through a program's source code. Read more about cyclomatic complexity on Wikipedia. |
| maxlen | This option lets you set the maximum length of a line. |
| asi | This option suppresses warnings about missing semicolons. There is a lot of FUD about semicolon spread by quite a few people in the community. The common myths are that semicolons are required all the time (they are not) and that they are unreliable. JavaScript has rules about semicolons which are followed by all browsers so it is up to you to decide whether you should or should not use semicolons in your code. For more information about semicolons in JavaScript read An Open Letter to JavaScript Leaders Regarding Semicolons by Isaac Schlueter and JavaScript Semicolon Insertion. |
| boss | This option suppresses warnings about the use of assignments in cases where
comparisons are expected. More often than not, code like |
| debug | This option suppresses warnings about the |
| eqnull | This option suppresses warnings about |
| esnext | This option tells JSHint that your code uses ECMAScript 6 specific syntax. Note that these features are not finalized yet and not all browsers implement them. More info: |
| evil | This option suppresses warnings about the use of |
| expr | This option suppresses warnings about the use of expressions where normally you would expect to see assignments or function calls. Most of the time, such code is a typo. However, it is not forbidden by the spec and that's why this warning is optional. |
| funcscope | This option suppresses warnings about declaring variables inside of control structures while accessing them later from the outside. Even though JavaScript has only two real scopes—global and function—such practice leads to confusion among people new to the language and hard-to-debug bugs. This is why, by default, JSHint warns about variables that are used outside of their intended scope. |
| globalstrict | This option suppresses warnings about the use of global strict mode. Global strict mode can break third-party widgets so it is not recommended. For more info about strict mode see the |
| iterator | This option suppresses warnings about the |
| lastsemic | This option suppresses warnings about missing semicolons, but only when the semicolon is omitted for the last statement in a one-line block:
This is a very niche use case that is useful only when you use automatic JavaScript code generators. |
| laxbreak | This option suppresses most of the warnings about possibly unsafe line breakings
in your code. It doesn't suppress warnings about comma-first coding style. To
suppress those you have to use |
| laxcomma | This option suppresses warnings about comma-first coding style: |
| loopfunc | This option suppresses warnings about functions inside of loops. Defining functions inside of loops can lead to bugs such as this one:
To fix the code above you need to copy the value of |
| moz | This options tells JSHint that your code uses Mozilla JavaScript extensions. Unless you develop specifically for the Firefox web browser you don't need this option. More info: |
| multistr | This option suppresses warnings about multi-line strings. Multi-line strings
can be dangerous in JavaScript because all hell breaks loose if you accidentally
put a whitespace in between the escape character ( Note that even though this option allows correct multi-line strings, it still warns about multi-line strings without escape characters or with anything in between the escape character and a whitespace. |
| proto | This option suppresses warnings about the |
| scripturl | This option suppresses warnings about the use of script-targeted URLs—such as
|
| smarttabs | This option suppresses warnings about mixed tabs and spaces when the latter are used for alignmnent only. The technique is called SmartTabs. |
| shadow | This option suppresses warnings about variable shadowing i.e. declaring a variable that had been already declared somewhere in the outer scope. |
| sub | This option suppresses warnings about using |
| supernew | This option suppresses warnings about "weird" constructions like
|
| validthis | This option suppresses warnings about possible strict violations when the code
is running in strict mode and you use Note: This option can be used only inside of a function scope. JSHint will fail with an error if you will try to set this option globally. |
These options pre-define global variables that are exposed by popular JavaScript libraries and runtime environments—such as browser or Node. Essentially they are shortcuts for explicit declarations like /*global $:false, jQuery:false */.
| browser | This option defines globals exposed by modern browsers: all the way from good
old Note: This option doesn't expose variables like |
| couch | This option defines globals exposed by CouchDB. CouchDB is a document-oriented database that can be queried and indexed in a MapReduce fashion using JavaScript. |
| devel | This option defines globals that are usually used for logging poor-man's
debugging: |
| dojo | This option defines globals exposed by the Dojo Toolkit. |
| jquery | This option defines globals exposed by the jQuery JavaScript library. |
| mootools | This option defines globals exposed by the MooTools JavaScript framework. |
| node | This option defines globals available when your code is running inside of the Node runtime environment. Node.js is a server-side JavaScript environment that uses an asynchronous event-driven model. |
| nonstandard | This option defines non-standard but widely adopted globals such as |
| prototypejs | This option defines globals exposed by the Prototype JavaScript framework. |
| rhino | This option defines globals available when your code is running inside of the Rhino runtime environment. Rhino is an open-source implementation of JavaScript written entirely in Java. |
| worker | This option defines globals available when your code is running inside of a Web Worker. Web Workers provide a simple means for web content to run scripts in background threads. |
| wsh | This option defines globals available when your code is running as a script for the Windows Script Host. |
| yui | This option defines globals exposed by the YUI JavaScript framework. |
These options are legacy from JSLint. Aside from bug fixes they will not be improved in any way and might be removed at any point.
| nomen | This option disallows the use of dangling |
| onevar | This option allows only one |
| passfail | This option makes JSHint stop on the first error or warning. |
| white | This option make JSHint check your source code against Douglas Crockford's JavaScript coding style. Unfortunately, his “The Good Parts” book aside, the actual rules are not very well documented. |
If you have any further questions about JSHint, feel free to send them to our mailing list.