# Jshint > This page's content is sourced from --- # Source: https://jshint.com/about/ About JSHint JSHint About Docs Install Contribute Blog Jump to docs 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 ! JSHint, A Static Code Analysis Tool for JavaScript [ Use it online • Docs • FAQ • Install • Contribute • Blog • Twitter ] JSHint is a community-driven tool that detects errors and potential problems in JavaScript code. Since JSHint is so flexible, you can easily adjust it in the environment you expect your code to execute. JSHint is publicly available and will always stay this way. Our goal The project aims to help JavaScript developers write complex programs without worrying about typos and language gotchas. Any code base eventually becomes huge at some point, so simple mistakes — that would not show themselves when written — can become show stoppers and add extra hours of debugging. So, static code analysis tools come into play and help developers spot such problems. JSHint scans a program written in JavaScript and reports about commonly made mistakes and potential bugs. The potential problem could be a syntax error, a bug due to an implicit type conversion, a leaking variable, or something else entirely. Only 15% of all programs linted on jshint.com pass the JSHint checks. In all other cases, JSHint finds some red flags that could've been bugs or potential problems. Please note, that while static code analysis tools can spot many different kind of mistakes, it can't detect if your program is correct, fast or has memory leaks. You should always combine tools like JSHint with unit and functional tests as well as with code reviews. Reporting a bug To report a bug simply create a new GitHub Issue and describe your problem or suggestion. We welcome all kinds of feedback regarding JSHint including but not limited to: When JSHint doesn't work as expected When JSHint complains about valid JavaScript code that works in all browsers When you simply want a new option or feature Before reporting a bug, please look around to see if there are any open or closed tickets that discuss your issue, and remember the wisdom: pull request > bug report > tweet. Who uses JSHint? Engineers from these companies and projects use JSHint: Mozilla Wikipedia Facebook Twitter Disqus Medium Yahoo! SmugMug jQuery UI ( Source ) jQuery Mobile ( Source ) Coursera RedHat SoundCloud Nodejitsu Yelp Find My Electric Voxer EnyoJS QuickenLoans Cloud9 CodeClimate Zendesk Google Codacy ref Spotify And many more! License JSHint is licensed under the MIT Expat license . Prior to version 2.12.0 (release in August 2020), JSHint was partially licensed under the non-free JSON license . The 2020 Relicensing document details the process maintainers followed to change the license. The JSHint Team JSHint is currently maintained by Rick Waldron , Caitlin Potter , Mike Pennisi , and Luke Page . You can reach them via admin@jshint.org. Previous Maintainers Originating from the JSLint project in 2010, JSHint has been maintained by a number of dedicated individuals. In chronological order, they are: Douglas Crockford, Anton Kovalyov, and Mike Sherov. We appreciate their long-term commitment! Thank you! We really appreciate all kinds of feedback and contributions. Thanks for using and supporting JSHint! --- # Source: https://jshint.com/docs/api/ JSHint API JSHint About Docs Install Contribute Blog Jump to docs Application Programming Interface JSHint exposes a JavaScript API for programmatic access in environments like web browsers and Node.js . JSHINT( source, options, predef ) Analyze source code for errors and potential problems. Parameters: source Description: The input JavaScript source code Type: string or an array of strings (each element is interpreted as a newline) Example: JSHINT(["'use strict';", "console.log('hello, world!');"]); options Description: The linting options to use when analyzing the source code Type: an object whose property names are the desired options to use and whose property values are the configuration values for those properties. Example: JSHINT(mySource, { undef: true }); predef Description: variables defined outside of the current file; the behavior of this argument is identical to the globals linting option Type: an object whose property names are the global variable identifiers and whose property values control whether each variable should be considered read-only Example: JSHINT(mySource, myOptions, { jQuery: false }); JSHINT.errors An array of warnings and errors generated by the most recent invocation of JSHINT . JSHINT.data() Generate a report containing details about the most recent invocation of JSHINT . For example, the following code: var source = [ 'function goo() {}', 'foo = 3;' ]; var options = { undef: true }; var predef = { foo: false }; JSHINT(source, options, predef); console.log(JSHINT.data()); ...will produce the following output: { functions: [ { name: 'goo', param: undefined, line: 1, character: 14, last: 1, lastcharacter: 18, metrics: { complexity: 1, parameters: 0, statements: 0 } } ], options: { undef: true, indent: 4, maxerr: 50 }, errors: [ { id: '(error)', raw: 'Read only.', code: 'W020', evidence: 'foo = 3;', line: 2, character: 1, scope: '(main)', a: undefined, b: undefined, c: undefined, d: undefined, reason: 'Read only.' } ], globals: [ 'goo', 'foo' ], unused: [ { name: 'goo', line: 1, character: 10 } ] } --- # Source: https://jshint.com/docs/cli/ JSHint CLI flags JSHint About Docs Install Contribute Blog Jump to docs 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 ! Command-line Interface 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 Specifying Input 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. Specifying Linting Options 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: The location specified with the --config flag A file named package.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) A file named .jshintrc located in the current directory or any parent of the current directory A file named .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 Special Options The following options concern the file system and are only available from within configuration files (i.e. not from inline directives or the API): extends Use 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 } } overrides Specify 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 } } } Ignoring Files 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: The location specified with the --exclude-path flag A file named .jshintignore located in the current directory or any parent of the current directory If this search yields no results, jshint will not ignore any files. Flags --config Explicitly sets the location on the file system from which jshint should load linting options. $ jshint --config ../path/to/my/config.json --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). --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. --exclude Allows you to specify directories which you DON'T want to be linted. --exclude-path Allows you to provide your own .jshintignore file. For example, you can point JSHint to your .gitignore file and use it instead of default .jshintignore. --prereq Allows you to specify prerequisite files i.e. files which include definitions of global variables used throughout your project. --help Shows a nice little help message similar to what you're reading right now. --version Shows the installed version of JSHint. --- # Source: https://jshint.com/docs/faq/ FAQ JSHint About Docs Install Contribute Blog Jump to docs 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 ! Frequently Asked Questions Can I use multiple reporters at the same time? Yes, you may do so by authoring a new reporter that composes the reporters you are interested in using. For example, to use reporters named first-reporter and second-reporter , create a new module that invokes them both: var first = require('first-reporter'); var second = require('second-reporter'); exports.reporter = function(results, data, opts) { first.reporter(results, data, opts); second.reporter(results, data, opts); }; Save that to a file named dual-reporter.js , and run JSHint with: $ jshint --reporter ./dual-reporter.js ...and you should see the output of first-reporter followed by the output of second-reporter . This approach is especially well-suited to using the different reporters' output in different contexts (for instance, e-mailing one reporter's output to the development team and feeding another reporter's output to a continuous integration system). You might output a custom delimiter between the output streams in order to demultiplex them. Alternatively, you might replace the global process.stdout value with another stream between reporter invocations. This latter solution is somewhat fragile because it involves mutating global state--a future release of JSHint may expose a safer mechanism for this operation. See the documentation on JSHint's "reporter" API for more details on creating your own reporter. JSHint skips some unused variables If your code looks like this: function test(a, b, c) { return c; } Then JSHint will not warn about unused variables a and b if you set the unused option to true . It figures that if unused arguments are followed by used ones, it was a conscious decision and not a typo. If you want to warn about all unused variables not matter where they appear, set the unused option to strict : /*jshint unused:strict */ function test(a, b, c) { return c; } // Warning: unused variable 'a' // Warning: unused variable 'b' For more information see: options/unused . --- # Source: https://jshint.com/docs/options/ JSHint Options Reference JSHint About Docs Install Contribute Blog Jump to docs JSHint Options 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 ! Enforcing options When set to true, these options will make JSHint produce more warnings about your code. bitwise This option prohibits the use of bitwise operators such as ^ (XOR), | (OR) and others. Bitwise operators are very rare in JavaScript programs and quite often & is simply a mistyped && . camelcase Warning This option has been deprecated and will be removed in the next major release of JSHint. JSHint is limiting its scope to issues of code correctness. If you would like to enforce rules relating to code style, check out the JSCS project . 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: while (day) shuffle(); However, in some circumstances, it can lead to bugs (you'd think that sleep() is a part of the loop while in reality it is not): while (day) shuffle(); sleep(); enforceall Warning This option has been deprecated and will be removed in the next major release of JSHint. The option cannot be maintained without automatically opting users in to new features. This can lead to unexpected warnings/errors in when upgrading between minor versions of JSHint. This option is a short hand for the most strict JSHint configuration as available in JSHint version 2.6.3. It enables all enforcing options and disables all relaxing options that were defined in that release. eqeqeq This options prohibits the use of == and != in favor of === and !== . The former try to coerce values before comparing them which can lead to some unexpected results. The latter don't do any coercion so they are generally safer. If you would like to learn more about type coercion in JavaScript, we recommend Truth, Equality and JavaScript by Angus Croll. es3 Warning This option has been deprecated and will be removed in the next major release of JSHint. Use esversion: 3 instead. 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/9—and other legacy JavaScript environments. es5 Warning This option has been deprecated and will be removed in the next major release of JSHint. Use esversion: 5 instead. This option enables syntax first defined in the ECMAScript 5.1 specification . This includes allowing reserved keywords as object properties. esversion This option is used to specify the ECMAScript version to which the code must adhere. It can assume one of the following values: 3 - If you need your program to be executable in older browsers—such as Internet Explorer 6/7/8/9—and other legacy JavaScript environments 5 - To enable syntax first defined in the ECMAScript 5.1 specification . This includes allowing reserved keywords as object properties. 6 - To tell JSHint that your code uses ECMAScript 6 specific syntax. Note that not all browsers implement them. 7 - To enable language features introduced by ECMAScript 7 . Notable additions: the exponentiation operator. 8 - To enable language features introduced by ECMAScript 8 . Notable additions: async functions, shared memory, and atomics 9 - To enable language features introduced by ECMAScript 9 . Notable additions: asynchronous iteration, rest/spread properties, and various RegExp extensions 10 - To enable language features introduced by ECMAScript 10 . Notable additions: optional catch bindings. 11 - To enable language features introduced by ECMAScript 11. Notable additions: "export * as ns from 'module'", import.meta , the nullish coalescing operator, the BigInt type, the globalThis binding, optional chaining, and dynamic import. forin This option requires all for in loops to filter object's items. The for in statement allows for looping through the names of all of the properties of an object including those inherited through the prototype chain. This behavior can lead to unexpected items in your object so it is generally safer to always filter inherited properties out as shown in the example: for (key in obj) { if (obj.hasOwnProperty(key)) { // We are sure that obj[key] belongs to the object and was not inherited. } } For more in-depth understanding of for in loops in JavaScript, read Exploring JavaScript for-in loops by Angus Croll. freeze This options prohibits overwriting prototypes of native objects such as Array , Date and so on. // jshint freeze:true Array.prototype.count = function (value) { return 4; }; // -> Warning: Extending prototype of native object: 'Array'. futurehostile This option enables warnings about the use of identifiers which are defined in future versions of JavaScript. Although overwriting them has no effect in contexts where they are not implemented, this practice can cause issues when migrating codebases to newer versions of the language. globals This option can be used to specify a white list of global variables that are not formally defined in the source code. This is most useful when combined with the undef option in order to suppress warnings for project-specific global variables. Setting an entry to true enables reading and writing to that variable. Setting it to false will trigger JSHint to consider that variable read-only. See also the "environment" options: a set of options to be used as short hand for enabling global variables defined in common JavaScript environments. To configure globals within an individual file, see Inline Configuration . immed Warning This option has been deprecated and will be removed in the next major release of JSHint. JSHint is limiting its scope to issues of code correctness. If you would like to enforce rules relating to code style, check out the JSCS project . 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 Warning This option has been deprecated and will be removed in the next major release of JSHint. JSHint is limiting its scope to issues of code correctness. If you would like to enforce rules relating to code style, check out the JSCS project . This option sets a specific tab width for your code. 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. Setting this option to "nofunc" will allow function declarations to be ignored. For more in-depth understanding of scoping and hoisting in JavaScript, read JavaScript Scoping and Hoisting by Ben Cherry. leanswitch This option prohibits unnecessary clauses within switch statements, e.g. switch (x) { case 1: default: z(); } While clauses like these are techincally valid, they do not effect program behavior and may indicate an erroneous refactoring. 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 . maxdepth This option lets you control how nested do you want your blocks to be: // jshint maxdepth:2 function main(meaning) { var day = true; if (meaning === 42) { while (day) { shuffle(); if (tired) { // JSHint: Blocks are nested too deeply (3). sleep(); } } } } maxerr This options allows you to set the maximum amount of errors JSHint will produce before giving up. Default is 50. maxlen Warning This option has been deprecated and will be removed in the next major release of JSHint. JSHint is limiting its scope to issues of code correctness. If you would like to enforce rules relating to code style, check out the JSCS project . This option lets you set the maximum length of a line. maxparams This option lets you set the max number of formal parameters allowed per function: // jshint maxparams:3 function login(request, onSuccess) { // ... } // JSHint: Too many parameters per function (4). function logout(request, isManual, whereAmI, onSuccess) { // ... } maxstatements This option lets you set the max number of statements allowed per function: // jshint maxstatements:4 function main() { var i = 0; var j = 0; // Function declarations count as one statement. Their bodies // don't get taken into account for the outer function. function inner() { var i2 = 1; var j2 = 1; return i2 + j2; } j = i + j; return j; // JSHint: Too many statements per function. (5) } newcap Warning This option has been deprecated and will be removed in the next major release of JSHint. JSHint is limiting its scope to issues of code correctness. If you would like to enforce rules relating to code style, check out the JSCS project . This option requires you to capitalize names of constructor functions. Capitalizing functions that are intended to be used with new operator is just a convention that helps programmers to visually distinguish constructor functions from other types of functions to help spot mistakes when using this . 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 new is used without it, this will point to the global object instead of a new object. noarg This option prohibits the use of arguments.caller and arguments.callee . Both .caller and .callee make quite a few optimizations impossible so they were deprecated in future versions of JavaScript. In fact, ECMAScript 5 forbids the use of arguments.callee in strict mode. nocomma This option prohibits the use of the comma operator. When misused, the comma operator can obscure the value of a statement and promote incorrect code. noempty Warning This option has been deprecated and will be removed in the next major release of JSHint. JSHint is limiting its scope to issues of code correctness. If you would like to enforce rules relating to code style, check out the JSCS project . 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. nonbsp This option warns about "non-breaking whitespace" characters. These characters can be entered with option-space on Mac computers and have a potential of breaking non-UTF8 web pages. 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: new MyConstructor(); There is no advantage in this approach over simply calling MyConstructor since the object that the operator new creates isn't used anywhere so you should generally avoid constructors like this one. noreturnawait Async functions resolve on their return value. In most cases, this makes returning the result of an AwaitExpression (which is itself a Promise instance) unnecessary. For clarity, it's often preferable to return the result of the asynchronous operation directly. The notable exception is within the try clause of a TryStatement--for more, see "await vs return vs return await": https://jakearchibald.com/2017/await-vs-return-vs-return-await/ predef This option allows you to control which variables JSHint considers to be implicitly defined in the environment. Configure it with an array of string values. Prefixing a variable name with a hyphen (-) character will remove that name from the collection of predefined variables. JSHint will consider variables declared in this way to be read-only. This option cannot be specified in-line; it may only be used via the JavaScript API or from an external configuration file. quotmark Warning This option has been deprecated and will be removed in the next major release of JSHint. JSHint is limiting its scope to issues of code correctness. If you would like to enforce rules relating to code style, check out the JSCS project . This option enforces the consistency of quotation marks used throughout your code. It accepts three values: true if you don't want to enforce one particular style but want some consistency, "single" if you want to allow only single quotes and "double" if you want to allow only double quotes. regexpu This option enables warnings for regular expressions which do not include the "u" flag. The "u" flag extends support for Unicode and also enables more strict parsing rules. JSHint will enforce these rules even if it is executed in a JavaScript engine which does not support the "u" flag. shadow This option suppresses warnings about variable shadowing i.e. declaring a variable that had been already declared somewhere in the outer scope. "inner" - check for variables defined in the same scope only "outer" - check for variables defined in outer scopes as well false - same as inner true - allow variable shadowing singleGroups This option prohibits the use of the grouping operator when it is not strictly required. Such usage commonly reflects a misunderstanding of unary operators, for example: // jshint singleGroups: true delete(obj.attr); // Warning: Unnecessary grouping operator. strict This option requires the code 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. "global" - there must be a "use strict"; directive at global level "implied" - lint the code as if there is the "use strict"; directive false - disable warnings about strict mode true - there must be a "use strict"; directive at function level; this is preferable for scripts intended to be loaded in web browsers directly because enabling strict mode globally could adversely effect other scripts running on the same page trailingcomma This option warns when a comma is not placed after the last element in an array or object literal. Due to bugs in old versions of IE, trailing commas used to be discouraged, but since ES5 their semantics were standardized. (See #11.1.4 and #11.1.5 .) Now, they help to prevent the same visual ambiguities that the strict usage of semicolons helps prevent. For example, this code might have worked last Tuesday: [ b + c ].forEach(print); But if one adds an element to the array and forgets to compensate for the missing comma, no syntax error is thrown, and a linter cannot determine if this was a mistake or an intentional function invocation. [ b + c (d + e) ].forEach(print); If one always appends a list item with a comma, this ambiguity cannot occur: [ b + c, ].forEach(print); [ b + c, (d + e), ].forEach(print); undef This option prohibits the use of explicitly undeclared variables. This option is very useful for spotting leaking and mistyped variables. // jshint undef:true function test() { var myVar = 'Hello, World'; console.log(myvar); // Oops, typoed here. JSHint with undef will complain } If your variable is defined in another file, you can use the global directive to tell JSHint about it. 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 undef . // jshint unused:true function test(a, b) { var c, d = 2; return a + d; } test(1, 2); // Line 3: 'b' was defined but never used. // Line 4: 'c' was defined but never used. In addition to that, this option will warn you about unused global variables declared via the global directive. When set to true , unused parameters that are followed by a used parameter will not produce warnings. This option can be set to vars to only check for variables, not function parameters, or strict to check all variables and parameters. varstmt When set to true, the use of VariableStatements are forbidden. For example: // jshint varstmt: true var a; // Warning: `var` declarations are forbidden. Use `let` or `const` instead. Relaxing options When set to true, these options will make JSHint produce fewer warnings about your code. 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 if (a = 10) {} is a typo. However, it can be useful in cases like this one: for (var i = 0, person; person = people[i]; i++) {} You can silence this error on a per-use basis by surrounding the assignment with parenthesis, such as: for (var i = 0, person; (person = people[i]); i++) {} debug This option suppresses warnings about the debugger statements in your code. elision This option tells JSHint that your code uses ES3 array elision elements, or empty elements (for example, [1, , , 4, , , 7] ). eqnull This option suppresses warnings about == null comparisons. Such comparisons are often useful when you want to check if a variable is null or undefined . esnext Warning This option has been deprecated and will be removed in the next major release of JSHint. Use esversion: 6 instead. This option tells JSHint that your code uses ECMAScript 6 specific syntax. Note that not all browsers implement these features. More info: Specification for ECMAScript 6 evil This option suppresses warnings about the use of eval . The use of eval is discouraged because it can make your code vulnerable to various injection attacks and it makes it hard for JavaScript interpreter to do certain optimizations. 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 identifiers declared with var have 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. function test() { if (true) { var x = 0; } x += 1; // Default: 'x' used out of scope. // No warning when funcscope:true } globalstrict Warning This option has been deprecated and will be removed in the next major release of JSHint. Use strict: "global" . 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 strict option. iterator This option suppresses warnings about the __iterator__ property. This property is not supported by all browsers so use it carefully. lastsemic This option suppresses warnings about missing semicolons, but only when the semicolon is omitted for the last statement in a one-line block: var name = (function() { return 'Anton' }()); This is a very niche use case that is useful only when you use automatic JavaScript code generators. laxbreak Warning This option has been deprecated and will be removed in the next major release of JSHint. JSHint is limiting its scope to issues of code correctness. If you would like to enforce rules relating to code style, check out the JSCS project . 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 (see below). laxcomma Warning This option has been deprecated and will be removed in the next major release of JSHint. JSHint is limiting its scope to issues of code correctness. If you would like to enforce rules relating to code style, check out the JSCS project . This option suppresses warnings about comma-first coding style: var obj = { name: 'Anton' , handle: 'valueof' , role: 'SW Engineer' }; loopfunc This option suppresses warnings about functions inside of loops. Defining functions inside of loops can lead to bugs such as this one: var nums = []; for (var i = 0; i < 10; i++) { nums[i] = function (j) { return i + j; }; } nums[0](2); // Prints 12 instead of 2 To fix the code above you need to copy the value of i : var nums = []; for (var i = 0; i < 10; i++) { (function (i) { nums[i] = function (j) { return i + j; }; }(i)); } 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: New in JavaScript 1.7 multistr Warning This option has been deprecated and will be removed in the next major release of JSHint. JSHint is limiting its scope to issues of code correctness. If you would like to enforce rules relating to code style, check out the JSCS project . 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 ( \ ) and a new line. 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. // jshint multistr:true var text = "Hello\ World"; // All good. text = "Hello World"; // Warning, no escape character. text = "Hello\ World"; // Warning, there is a space after \ notypeof This option suppresses warnings about invalid typeof operator values. This operator has only a limited set of possible return values . By default, JSHint warns when you compare its result with an invalid value which often can be a typo. // 'fuction' instead of 'function' if (typeof a == "fuction") { // Invalid typeof value 'fuction' // ... } Do not use this option unless you're absolutely sure you don't want these checks. noyield This option suppresses warnings about generator functions with no yield statement in them. plusplus This option prohibits the use of unary increment and decrement operators. Some people think that ++ and -- reduces the quality of their coding styles and there are programming languages—such as Python—that go completely without these operators. proto This option suppresses warnings about the __proto__ property. scripturl This option suppresses warnings about the use of script-targeted URLs—such as javascript:... . sub Warning This option has been deprecated and will be removed in the next major release of JSHint. JSHint is limiting its scope to issues of code correctness. If you would like to enforce rules relating to code style, check out the JSCS project . This option suppresses warnings about using [] notation when it can be expressed in dot notation: person['name'] vs. person.name . supernew This option suppresses warnings about "weird" constructions like new function () { ... } and new Object; . Such constructions are sometimes used to produce singletons in JavaScript: var singleton = new function() { var privateVar; this.publicMethod = function () {} this.publicMethod2 = function () {} }; validthis This option suppresses warnings about possible strict violations when the code is running in strict mode and you use this in a non-constructor function. You should use this option—in a function scope only—when you are positive that your use of this is valid in the strict mode (for example, if you call your function using Function.call ). 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. withstmt This option suppresses warnings about the use of the with statement. The semantics of the with statement can cause confusion among developers and accidental definition of global variables. More info: with Statement Considered Harmful Environments These options let JSHint know about some pre-defined global variables. browser This option defines globals exposed by modern browsers: all the way from good old document and navigator to the HTML5 FileReader and other new developments in the browser world. Note: This option doesn't expose variables like alert or console . See option devel for more information. browserify This option defines globals available when using the Browserify tool to build a project. 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: console , alert , etc. It is usually a good idea to not ship them in production because, for example, console.log breaks in legacy versions of Internet Explorer. dojo This option defines globals exposed by the Dojo Toolkit . jasmine This option defines globals exposed by the Jasmine unit testing framework . jquery This option defines globals exposed by the jQuery JavaScript library. mocha This option defines globals exposed by the "BDD" and "TDD" UIs of the Mocha unit testing framework . module This option informs JSHint that the input code describes an ECMAScript 6 module. All module code is interpreted as strict mode code. 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. This option also skips some warnings that make sense in the browser environments but don't make sense in Node such as file-level use strict pragmas and console.log statements. nonstandard This option defines non-standard but widely adopted globals such as escape and unescape . phantom This option defines globals available when your core is running inside of the PhantomJS runtime environment. PhantomJS is a headless WebKit scriptable with a JavaScript API. It has fast and native support for various web standards: DOM handling, CSS selector, JSON, Canvas, and SVG. prototypejs This option defines globals exposed by the Prototype JavaScript framework. qunit This option defines globals exposed by the QUnit unit testing 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. shelljs This option defines globals exposed by the ShellJS library . typed This option defines globals for typed array constructors. More info: JavaScript typed arrays 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. Unstable These options enable behavior which is subject to change between major releases of JSHint. Exercise caution when enabling them in automated environments (e.g. continuous integration). exports.unstable = { }; // These are JSHint boolean options which are shared with JSLint // where the definition in JSHint is opposite JSLint exports.inverted = { bitwise Unstable options allow control for parsing and linting of proposed additions to the JavaScript language. Just like the language features they describe, the presence and behavior of these options is volatile; JSHint reserves the right to remove or modify them between major version releases. --- # Source: https://jshint.com/docs/reporters/ Writing your own JSHint reporter JSHint About Docs Install Contribute Blog Jump to docs 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 ! Writing your own JSHint reporter JSHint Reporter is a JavaScript file that accepts raw data from JSHint and outputs something into the console (or another file, or sends an email; it's really up to you). Here's the simplest reporter, the one that prints OK if JSHint passed the file and FAIL if it didn't: module.exports = { reporter: function (errors) { console.log(errors.length ? "FAIL" : "OK"); } }; Each reporter file must expose one function, reporter , that accepts an array of errors. Each entry of this array has the following structure: { file: [string, filename] error: { id: [string, usually '(error)'], code: [string, error/warning code], reason: [string, error/warning message], evidence: [string, a piece of code that generated this error] line: [number] character: [number] scope: [string, message scope; usually '(main)' unless the code was eval'ed] [+ a few other legacy fields that you don't need to worry about.] } } And a real-world example: [ { file: 'demo.js', error: { id: '(error)', code: 'W117', reason: '\'module\' is not defined.' evidence: 'module.exports = {', line: 3, character: 1, scope: '(main)', // [...] } }, // [...] ] If you're still confused, JSHint repository has an example reporter . --- # Source: https://jshint.com/docs/ JSHint Documentation JSHint About Docs Install Contribute Blog Jump to docs Documentation 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 Basic usage 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: As a command-line tool (via Node.js ) As a JavaScript module 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. Configuration 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 } } Inline configuration 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. Directives Here's a list of configuration directives supported by JSHint: jshint A directive for setting JSHint options. /* jshint strict: true */ jslint A directive for setting JSHint-compatible JSLint options. /* jslint vars: true */ globals 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 */ exported 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 */ members A directive for telling JSHint about all properties you intend to use. This directive is deprecated. ignore 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:line Options 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: This syntax works only with warnings (code starts with W ), it doesn't work with errors (code starts with E ). This syntax will disable all warnings with this code. Some warnings are more generic than others so be cautious. 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. Switch statements 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(); } --- # Source: https://jshint.com/install/ Download and install JSHint About Docs Install Contribute Blog Jump to docs 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 ! Download and install JSHint runs in a number of different environments; installation is different for each. Browser-like environments A standalone files is built for browser-like environments with every release. You'll find it in the dist directory of the download. Download the latest release here . Rhino A standalone files is built for Mozilla's Rhino JavaScript engine with every release. You'll find it in the dist directory of the download. Download the latest release here . Node.js Each release of JSHint is published to npm , the package manager for the Node.js platform . You may install it globally using the following command: npm install -g jshint After this, you can use the jshint command-line interface. It is common to install JSHint as a development dependency within an existing Node.js project: npm install --save-dev jshint Plugins for text editors and IDEs VIM jshint.vim , VIM plugin and command line tool for running JSHint. jshint2.vim , modern VIM plugin with extra features for running JSHint. Syntastic , supports JSHint both older/newer than 1.1.0. Emacs jshint-mode , JSHint mode for GNU Emacs. Flycheck , on-the-fly syntax checking extension for GNU Emacs, built-in JSHint support. web-mode , an autonomous major-mode for editing web templates supports JSHint. Sublime Text Sublime-JSHint Gutter , JSHint plugin for graphically displaying lint results in ST2 and ST3. sublime-jshint , JSHint build package for ST2. Sublime Linter , inline lint highlighting for ST2. Atom linter-jshint , JSHint plugin for Atom's Linter. JSHint for Atom , JSHint package for Atom. TextMate JSHint Bundle for TextMate 2 JSHint TextMate Bundle . JSLintMate (supports both JSHint and JSLint). JSHint-external TextMate Bundle Visual Studio SharpLinter (supports both JSLint and JSHint). JSLint for Visual Studio (supports both JSLint and JSHint). Web Essentials (Runs JSHint automatically). Visual Studio Code VS Code JSHint extension , integrates JSHint into VS Code. Brackets Brackets JSHint plugin Brackets Interactive Linter Other ShiftEdit IDE has built-in support for JSHint. Komodo 7 now ships with built-in support for JSHint. JSHint integration for the Eclipse IDE JSHint integration for the NetBeans IDE JetBrains IDE family supports realtime code inspection with both JSHint and JSLint out of the box. JSLint plugin for Notepad++ now supports JSHint. JSHint plugin for Gedit . Other cool stuff JSHintr is a web tool that allows you to set your own code standards, easily review a file against these standards, and share the output with other developers. FixMyJS is a tool that automatically fixes mistakes—such as missing semicolon, multiple definitions, etc.—reported by JSHint. A ruby gem for JSHint . Another ruby gem but without Java dependency. pre-commit checks your code for errors before you commit it. Dedicated Ant task to easily automate JSHint in Ant Maven. QHint - JSHint in QUnit . Check for errors in your code from within your unit tests. Lint errors result in failed tests. Grunt , a task-based command line build tool for JavaScript projects, supports JSHint out of the box. overcommit is an extensible Git hook manager with built-in JSHint linting, distributed as a Ruby gem. Read more about it. jshint-mojo , a plugin for Maven. JSXHint , a wrapper around JSHint to allow linting of files containing JSX syntax.