This page's content is sourced from the JSHint project repository. If you spot an error, please open an issue or (better yet) make a pull request!
The JSHint CLI can be installed via npm (see the Installation page for instructions).
Contents: Specifying Input · Specifying Linting Options · Special Options · Ignoring Files · Flags
The jshint executable accepts file system paths as command-line arguments. If
a provided path describes a file, the executable will read that file and lint
the JavaScript code it contains:
$ jshint myfile.js
myfile.js: line 10, col 39, Octal literals are not allowed in strict mode.
1 error
If a provided path describes a file system directory, JSHint will traverse the directory and any subdirectories recursively, reading all JavaScript files and linting their contents:
$ tree a-directory/
a-directory/
├── file-1.js
└── nested
└── file-2.js
1 directory, 2 files
$ jshint a-directory/
a-directory/file-1.js: line 3, col 1, 'with' is not allowed in strict mode.
a-directory/nested/file-2.js: line 3, col 3, Unreachable 'void' after 'return'.
2 errors
If a file path is a dash (-) then JSHint will read from standard input.
The jshint executable is capable of applying linting
options specified in an external
JSON-formatted file. Such a file might look like this:
{
"curly": true,
"eqeqeq": true,
"nocomma": true
}
jshint will look for this configuration in a number of locations, stopping at
the first positive match:
--config flagpackage.json located in the current directory or any parent
of the current directory (the configuration should be declared as the
jshintConfig attribute of that file's JSON value).jshintrc located in the current directory or any parent of
the current directory.jshintrc located in the current user's "home" directory
(where defined)If this search yields no results, jshint will lint the input code as if no
linting rules had been enabled.
The command-line interface offers some special options in addition to the ones available in other contexts
The following options concern the file system and are only available from within configuration files (i.e. not from inline directives or the API):
extendsUse another configuration file as a "base". The value of this option should be a file path to another configuration file, and the path should be relative to the current file.
For example, you might define a .jshintrc file in the top-level directory of
your project (say, ./.jshintrc) to specify the linting
options you would like to use in your entire project:
{
"undef": true,
"unused": true
}
You may want to re-use this configuration for your project's automated tests,
but also allow for global
variables that are specific to the
test environment. In this case, you could create a a new file in their test
directory, (./test/.jshintrc for example), and include the following
configuration:
{
"extends": "../.jshintrc",
"globals": {
"test": false,
"assert": false
}
}
overridesSpecify options that should only be applied to files matching a given path pattern.
The following configuration file disallows variable
shadowing for all files and allows
expressions as statements for only those
files ending in -test.js:
{
"shadow": false,
"overrides": {
"lib/*-test.js": {
"expr": true
}
}
}
jshint can be configured to ignore files based on their location in the
filesystem. You may create a dedicated "ignore" file to list any number of file
names, file paths, or file path patterns that should not be linted. Path
patterns will be interpreted using the minimatch npm
module, which itself is based on the
Unix filename matching syntax, fnmatch.
build/
src/**/tmp.js
jshint will look for this configuration in a number of locations, stopping at
the first positive match:
--exclude-path flag.jshintignore located in the current directory or any parent
of the current directoryIf this search yields no results, jshint will not ignore any files.
--configExplicitly sets the location on the file system from which jshint should load
linting options.
$ jshint --config ../path/to/my/config.json
--reporterAllows 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.
--verboseAdds message codes to the JSHint output.
--show-non-errorsShows 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-extAllows you to specify additional file extensions to check (default is .js).
--extract=[auto|always|never]Tells JSHint to extract JavaScript from HTML files before linting:
tmp ☭ cat test.html
<html>
<head>
<title>Hello, World!</title>
<script>
function hello() {
return "Hello, World!";
}
</script>
</head>
<body>
<h1>Hello, World!</h1>
<script>
console.log(hello())
</script>
</body>
</html>
tmp ☭ jshint --extract=auto test.html
test.html: line 13, col 27, Missing semicolon.
1 error
If you set it to always JSHint will always attempt to extract JavaScript. And if you set it to auto it will make an attempt only if file looks like it's an HTML file.
--excludeAllows you to specify directories which you DON'T want to be linted.
--exclude-pathAllows you to provide your own .jshintignore file. For example, you can point JSHint to your .gitignore file and use it instead of default .jshintignore.
--prereqAllows you to specify prerequisite files i.e. files which include definitions of global variables used throughout your project.
--helpShows a nice little help message similar to what you're reading right now.
--versionShows the installed version of JSHint.