Command Line Interface
The ESLint Command Line Interface (CLI) lets you execute linting from the terminal. The CLI has a variety of options that you can pass to configure ESLint.
Run the CLI
ESLint requires Node.js for installation. Follow the instructions in the Getting Started Guide to install ESLint.
Most users use
npx to run ESLint on the command line like this:
npx eslint [options] [file|dir|glob]*
# Run on two files
npx eslint file1.js file2.js
# Run on multiple files
npx eslint lib/**
Please note that when passing a glob as a parameter, it is expanded by your shell. The results of the expansion can vary depending on your shell, and its configuration. If you want to use node
glob syntax, you have to quote your parameter (using double quotes if you need it to run in Windows), as follows:
npx eslint "lib/**"
The command line utility has several options. You can view the options by running
npx eslint -h.
eslint [options] file.js [file.js] [dir]
--no-eslintrc Disable use of configuration from .eslintrc.*
-c, --config path::String Use this configuration, overriding .eslintrc.* config options if present
--env [String] Specify environments
--global [String] Define global variables
--parser String Specify the parser to be used
--parser-options Object Specify parser options
--resolve-plugins-relative-to path::String A folder where plugins should be resolved from, CWD by default
Specifying rules and plugins:
--plugin [String] Specify plugins
--rule Object Specify rules
--rulesdir [path::String] Load additional rules from this directory. Deprecated: Use rules from plugins
--fix Automatically fix problems
--fix-dry-run Automatically fix problems without saving the changes to the file system
--fix-type Array Specify the types of fixes to apply (directive, problem, suggestion, layout)
--ignore-path path::String Specify path of ignore file
--no-ignore Disable use of ignore files and patterns
--ignore-pattern [String] Pattern of files to ignore (in addition to those in .eslintignore)
--stdin Lint code provided on
- default: false
--stdin-filename String Specify filename to process STDIN as
--quiet Report errors only - default: false
--max-warnings Int Number of warnings to trigger nonzero exit code - default: -1
-o, --output-file path::String Specify file to write report to
-f, --format String Use a specific output format - default: stylish
--color, --no-color Force enabling/disabling of color
Inline configuration comments:
--no-inline-config Prevent comments from changing config or rules
--report-unused-disable-directives Adds reported errors for unused eslint-disable directives
--cache Only check changed files - default: false
--cache-file path::String Path to the cache file. Deprecated: use --cache-location - default: .eslintcache
--cache-location path::String Path to the cache file or directory
--cache-strategy String Strategy to use for detecting changed files in the cache - either: metadata or content - default: metadata
--init Run config initialization wizard - default: false
--env-info Output execution environment information - default: false
--no-error-on-unmatched-pattern Prevent errors when pattern is unmatched
--exit-on-fatal-error Exit with exit code 2 in case of fatal error - default: false
--debug Output debugging information
-h, --help Show help
-v, --version Output the version number
--print-config path::String Print the configuration for the given file
Options that accept array values can be specified by repeating the option or with a comma-delimited list (other than
--ignore-pattern which does not allow the second style).
npx eslint --ext .jsx --ext .js lib/
npx eslint --ext .jsx,.js lib/
Disables use of configuration from
npx eslint --no-eslintrc file.js
This option allows you to specify an additional configuration file for ESLint (see Configuring ESLint for more).
npx eslint -c ~/my-eslint.json file.js
This example uses the configuration file at
package.json files are also used for configuration (i.e.,
--no-eslintrc was not specified), the configurations are merged. Options from this configuration file have precedence over the options from
This option enables specific environments. Details about the global variables defined by each environment are available on the Specifying Environments documentation. This option only enables environments; it does not disable environments set in other configuration files. To specify multiple environments, separate them using commas, or use the option multiple times.
npx eslint --env browser,node file.js
npx eslint --env browser --env node file.js
This option allows you to specify which file extensions ESLint uses when searching for target files in the directories you specify.
By default, ESLint lints
*.js files and the files that match the
overrides entries of your configuration.
# Use only .ts extension
npx eslint . --ext .ts
# Use both .js and .ts
npx eslint . --ext .js --ext .ts
# Also use both .js and .ts
npx eslint . --ext .js,.ts
--ext is only used when the arguments are directories. If you use glob patterns or file names, then
--ext is ignored.
npx eslint lib/* --ext .js matches all files within the
lib/ directory, regardless of extension.
This option defines global variables so that they are not flagged as
undefined by the
no-undef rule. Any specified global variables are assumed to be read-only by default, but appending
:true to a variable’s name ensures that
no-undef also allows writes. To specify multiple global variables, separate them using commas, or use the option multiple times.
npx eslint --global require,exports:true file.js
npx eslint --global require --global exports:true
This option allows you to specify a parser to be used by ESLint. By default,
espree is used.
This option allows you to specify parser options to be used by ESLint. Note that the available parser options are determined by the parser being used.
echo '3 ** 4' | npx eslint --stdin --parser-options=ecmaVersion:6 # fails with a parsing error
echo '3 ** 4' | npx eslint --stdin --parser-options=ecmaVersion:7 # succeeds, yay!
Changes the folder where plugins are resolved from. By default, plugins are resolved from the current working directory. This option should be used when plugins were installed by someone other than the end user. It should be set to the project directory of the project that has a dependency on the necessary plugins. For example:
- When using a config file that is located outside of the current project (with the
--configflag), if the config uses plugins which are installed locally to itself,
--resolve-plugins-relative-toshould be set to the directory containing the config file.
- If an integration has dependencies on ESLint and a set of plugins, and the tool invokes ESLint on behalf of the user with a preset configuration, the tool should set
--resolve-plugins-relative-toto the top-level directory of the tool.
Specifying rules and plugins
This option specifies a plugin to load. You can omit the prefix
eslint-plugin- from the plugin name.
Before using the plugin, you have to install it using npm.
npx eslint --plugin jquery file.js
npx eslint --plugin eslint-plugin-mocha file.js
This option specifies the rules to be used. These rules are merged with any rules specified with configuration files. (You can use
--no-eslintrc to change that behavior.) To define multiple rules, separate them using commas, or use the option multiple times. The levn format is used for specifying the rules.
If the rule is defined within a plugin, you have to prefix the rule ID with the plugin name and a
npx eslint --rule 'quotes: [error, double]'
npx eslint --rule 'guard-for-in: error' --rule 'brace-style: [error, 1tbs]'
npx eslint --rule 'jquery/dollar-sign: error'
Deprecated: Use rules from plugins instead.
This option allows you to specify another directory from which to load rules files. This allows you to dynamically load new rules at run time. This is useful when you have custom rules that aren’t suitable for being bundled with ESLint.
npx eslint --rulesdir my-rules/ file.js
The rules in your custom rules directory must follow the same format as bundled rules to work properly. You can also specify multiple locations for custom rules by including multiple
npx eslint --rulesdir my-rules/ --rulesdir my-other-rules/ file.js
Note that, as with core rules and plugin rules, you still need to enable the rules in configuration or via the
--rule CLI option in order to actually run those rules during linting. Specifying a rules directory with
--rulesdir does not automatically enable the rules within that directory.
This option instructs ESLint to try to fix as many issues as possible. The fixes are made to the actual files themselves and only the remaining unfixed issues are output. Not all problems are fixable using this option, and the option does not work in these situations:
- This option throws an error when code is piped to ESLint.
- This option has no effect on code that uses a processor, unless the processor opts into allowing autofixes.
If you want to fix code from
stdin or otherwise want to get the fixes without actually writing them to the file, use the
This option has the same effect as
--fix with one difference: the fixes are not saved to the file system. This makes it possible to fix code from
stdin (when used with the
Because the default formatter does not output the fixed code, you’ll have to use another one (e.g.
json) to get the fixes. Here’s an example of this pattern:
getSomeText | npx eslint --stdin --fix-dry-run --format=json
This flag can be useful for integrations (e.g. editor plugins) which need to autofix text from the command line without saving it to the filesystem.
This option allows you to specify the type of fixes to apply when using either
--fix-dry-run. The four types of fixes are:
problem- fix potential errors in the code
suggestion- apply fixes to the code that improve it
layout- apply fixes that do not change the program structure (AST)
directive- apply fixes to inline directives such as
You can specify one or more fix type on the command line. Here are some examples:
npx eslint --fix --fix-type suggestion .
npx eslint --fix --fix-type suggestion --fix-type problem .
npx eslint --fix --fix-type suggestion,layout .
This option is helpful if you are using another program to format your code but you would still like ESLint to apply other types of fixes.
--ignore-path is not supported when using flat config (
This option allows you to specify the file to use as your
.eslintignore. By default, ESLint looks in the current working directory for
.eslintignore. You can override this behavior by providing a path to a different file.
npx eslint --ignore-path tmp/.eslintignore file.js
npx eslint --ignore-path .gitignore file.js
Disables excluding of files from
ignorePatterns property in config files.
npx eslint --no-ignore file.js
This option allows you to specify patterns of files to ignore (in addition to those in
.eslintignore). You can repeat the option to provide multiple patterns. The supported syntax is the same as for
.eslintignore files, which use the same patterns as the
.gitignore specification. You should quote your patterns in order to avoid shell interpretation of glob patterns.
npx eslint --ignore-pattern '/lib/' --ignore-pattern '/src/vendor/*' .
This option tells ESLint to read and lint source code from STDIN instead of from files. You can use this to pipe code to ESLint.
cat myfile.js | npx eslint --stdin
This option allows you to specify a filename to process STDIN as. This is useful when processing files from STDIN and you have rules which depend on the filename.
cat myfile.js | npx eslint --stdin --stdin-filename=myfile.js
This option allows you to disable reporting on warnings. If you enable this option, only errors are reported by ESLint.
npx eslint --quiet file.js
This option allows you to specify a warning threshold, which can be used to force ESLint to exit with an error status if there are too many warning-level rule violations in your project.
Normally, if ESLint runs and finds no errors (only warnings), it exits with a success exit status. However, if
--max-warnings is specified and the total warning count is greater than the specified threshold, ESLint exits with an error status. To prevent this behavior, omit this option or specify a threshold of
npx eslint --max-warnings 10 file.js
Enable report to be written to a file.
npx eslint -o ./test/test.html
When specified, the given format is output into the provided file name.
This option specifies the output format for the console. Possible formats are:
npx eslint -f compact file.js
You can also use a custom formatter from the command line by specifying a path to the custom formatter file.
npx eslint -f ./customformat.js file.js
An npm-installed formatter is resolved with or without
npm install eslint-formatter-pretty
npx eslint -f pretty file.js
npx eslint -f eslint-formatter-pretty file.js
When specified, the given format is output to the console. If you’d like to save that output into a file, you can do so on the command line like so:
npx eslint -f compact file.js > results.txt
This saves the output into the
This option forces the enabling/disabling of colorized output. You can use this to override the default behavior, which is to enable colorized output unless no TTY is detected, such as when piping
npx eslint --color file.js | cat
npx eslint --no-color file.js
Inline configuration comments
This option prevents inline comments like
/*global foo*/ from having any effect. This allows you to set an ESLint
config without files modifying it. All inline config comments are ignored, e.g.:
npx eslint --no-inline-config file.js
This option causes ESLint to report directive comments like
// eslint-disable-line when no errors would have been reported on that line anyway. This can be useful to prevent future errors from unexpectedly being suppressed, by cleaning up old
eslint-disable comments which are no longer applicable.
Warning: When using this option, it is possible that new errors start being reported whenever ESLint or custom rules are upgraded. For example, suppose a rule has a bug that causes it to report a false positive, and an
eslint-disable comment is added to suppress the incorrect report. If the bug is then fixed in a patch release of ESLint, the
eslint-disable comment becomes unused since ESLint is no longer generating an incorrect report. This results in a new reported error for the unused directive if the
report-unused-disable-directives option is used.
npx eslint --report-unused-disable-directives file.js
Store the info about processed files in order to only operate on the changed ones. The cache is stored in
.eslintcache by default. Enabling this option can dramatically improve ESLint’s running time by ensuring that only changed files are linted.
Note: If you run ESLint with
--cache and then run ESLint without
.eslintcache file will be deleted. This is necessary because the results of the lint might change and make
.eslintcache invalid. If you want to control when the cache file is deleted, then use
--cache-location to specify an alternate location for the cache file.
Note: Autofixed files are not placed in the cache. Subsequent linting that does not trigger an autofix will place it in the cache.
Path to the cache file. If no file is specified,
.eslintcache is used. The file is created in the directory where the
eslint command is executed. Deprecated: Use
Path to the cache location. Can be a file or a directory. If no location is specified,
.eslintcache is used. In that case, the file is created in the directory where the
eslint command is executed.
If a directory is specified, a cache file is created inside the specified folder. The name of the file is based on the hash of the current working directory (CWD). e.g.:
Important note: If the directory for the cache does not exist make sure you add a trailing
/ on *nix systems or
\ in windows. Otherwise the path is assumed to be a file.
npx eslint "src/**/*.js" --cache --cache-location "/Users/user/.eslintcache/"
Strategy for the cache to use for detecting changed files. Can be either
content. If no strategy is specified,
metadata is used.
content strategy can be useful in cases where the modification time of your files changes even if their contents have not. For example, this can happen during git operations like git clone because git does not track file modification time.
npx eslint "src/**/*.js" --cache --cache-strategy content
This option runs
npm init @eslint/config to start the config initialization wizard. It’s designed to help new users quickly create an
.eslintrc.js file by answering a few questions and choosing a popular style guide.
The resulting configuration file is created in the current directory.
This option outputs information about the execution environment, including the version of Node, npm, and local and global installations of ESLint. The ESLint team may ask for this information to help solve bugs.
This option prevents errors when a quoted glob pattern or
--ext is unmatched. This does not prevent errors when your shell can’t match a glob.
This option causes ESLint to exit with exit code 2 if one or more fatal parsing errors occur. Without this option, fatal parsing errors are reported as rule violations.
This option outputs debugging information to the console. This information is useful when you’re seeing a problem and having a hard time pinpointing it. The ESLint team may ask for this debugging information to help solve bugs.
Add this flag to an ESLint command line invocation in order to get extra debug information as the command is run (e.g.
npx eslint --debug test.js and
npx eslint test.js --debug are equivalent)
This option outputs the help menu, displaying all of the available options. All other options are ignored when this is present.
This option outputs the current ESLint version onto the console. All other options are ignored when this is present.
This option outputs the configuration to be used for the file passed. When present, no linting is performed and only config-related options are valid.
npx eslint --print-config file.js
Ignoring files from linting
.eslintignore files to exclude files from the linting process when ESLint operates on a directory. Files given as individual CLI arguments are exempt from exclusion. The
.eslintignore file is a plain text file containing one pattern per line. It can be located in any of the target directory’s ancestors; it affects files in its containing directory as well as all sub-directories. Here’s a simple example of a
A more detailed breakdown of supported patterns and directories ESLint ignores by default can be found in Ignoring Code.
When linting files, ESLint exits with one of the following exit codes:
0: Linting was successful and there are no linting errors. If the
--max-warningsflag is set to
n, the number of linting warnings is at most
1: Linting was successful and there is at least one linting error, or there are more linting warnings than allowed by the
2: Linting was unsuccessful due to a configuration problem or an internal error.