jshint

jshint [options] [file ...]

-c, --config [file]
    Specifies a custom configuration file for JSHint, overriding default or project-level configurations.

-e, --exclude [file]
    Excludes specific files or directories from the linting process.

-r, --reporter [path]
    Uses a custom reporter script to format the output of JSHint. This allows for integration with various tools or custom reporting formats.

--extract [value]
    Controls how JavaScript code is extracted from non-JavaScript files (e.g., HTML). Possible values include 'always', 'auto', or 'never'.

--extra-ext [ext]
    A comma-separated list of additional file extensions (e.g., 'jsx,mjs') that JSHint should process as JavaScript.

--verbose
    Shows verbose output, providing more detailed information during the linting process, such as file paths being processed.

--prereqs
    Displays JSHint's prerequisites, typically showing the required Node.js version.

-v, --version
    Displays the installed version of JSHint.

-h, --help
    Shows the help message, listing all available command-line options and their usage.

JSHint is a static code analysis tool specifically designed for JavaScript. It helps developers maintain code quality by scanning JavaScript code for errors, potential bugs, and adherence to coding style guidelines. Unlike traditional debuggers, JSHint performs its analysis without executing the code, making it a powerful pre-commit or pre-deployment check.

It's highly configurable through a `.jshintrc` file or command-line options, allowing teams to enforce specific coding standards and catch common pitfalls like undeclared variables, missing semicolons, or improper use of global objects. By integrating JSHint into a development workflow, developers can significantly reduce the number of quality issues and improve the consistency and readability of their JavaScript codebase.

JSHint requires Node.js to be installed on the system to run. While still functional, it has largely been superseded by more modern and flexible linters like ESLint in many contemporary JavaScript development environments, which offer a more extensive plugin ecosystem and finer-grained control. Configuration, especially with multiple `.jshintrc` files in a project, can sometimes be complex.

JSHint primarily uses a configuration file named `.jshintrc` in the project root or subdirectory to define linting rules. These JSON-formatted files allow developers to enable/disable specific warnings, set global variables, and configure environments (e.g., browser, node). JSHint searches for `.jshintrc` files upwards through the directory tree, allowing for per-directory configurations.

When run as a command-line tool, JSHint uses exit codes to indicate the result of the linting process:
0: No errors or warnings were found.
1: An error occurred (e.g., invalid configuration, file not found).
2: Warnings were found in the analyzed code.
3: Errors were found in the analyzed code.

JSHint emerged as a fork of the original JSLint project in 2010. While JSLint was known for its highly opinionated and strict approach to JavaScript code quality, JSHint aimed to provide a more configurable and less opinionated alternative. The goal was to give developers more control over which rules to enforce, allowing them to tailor the linter to their specific project needs and coding styles, rather than adhering to a single, strict standard. This flexibility contributed to its widespread adoption in the JavaScript community for many years.

eslint(1), prettier(1), jslint