title | eleventyNavigation | ||||||||
---|---|---|---|---|---|---|---|---|---|
Configuration Files (New) |
|
::: tip This page explains how to use flat config files. For the deprecated eslintrc format, see the deprecated documentation. :::
You can put your ESLint project configuration in a configuration file. You can include built-in rules, how you want them enforced, plugins with custom rules, shareable configurations, which files you want rules to apply to, and more.
The ESLint configuration file is named eslint.config.js
. It should be placed in the root directory of your project and export an array of configuration objects. Here's an example:
// eslint.config.js
export default [
{
rules: {
semi: "error",
"prefer-const": "error"
}
}
];
In this example, the configuration array contains just one configuration object. The configuration object enables two rules: semi
and prefer-const
. These rules are applied to all of the files ESLint processes using this config file.
If your project does not specify "type":"module"
in its package.json
file, then eslint.config.js
must be in CommonJS format, such as:
// eslint.config.js
module.exports = [
{
rules: {
semi: "error",
"prefer-const": "error"
}
}
];
The configuration file can also export a promise that resolves to the configuration array. This can be useful for using ESM dependencies in CommonJS configuration files, as in this example:
// eslint.config.js
module.exports = (async () => {
const someDependency = await import("some-esm-dependency");
return [
// ... use `someDependency` here
];
})();
::: warning
ESLint only automatically looks for a config file named eslint.config.js
and does not look for eslint.config.cjs
or eslint.config.mjs
. If you'd like to specify a different config filename than the default, use the --config
command line option.
:::
Each configuration object contains all of the information ESLint needs to execute on a set of files. Each configuration object is made up of these properties:
files
- An array of glob patterns indicating the files that the configuration object should apply to. If not specified, the configuration object applies to all files matched by any other configuration object.ignores
- An array of glob patterns indicating the files that the configuration object should not apply to. If not specified, the configuration object applies to all files matched byfiles
.languageOptions
- An object containing settings related to how JavaScript is configured for linting.ecmaVersion
- The version of ECMAScript to support. May be any year (i.e.,2022
) or version (i.e.,5
). Set to"latest"
for the most recent supported version. (default:"latest"
)sourceType
- The type of JavaScript source code. Possible values are"script"
for traditional script files,"module"
for ECMAScript modules (ESM), and"commonjs"
for CommonJS files. (default:"module"
for.js
and.mjs
files;"commonjs"
for.cjs
files)globals
- An object specifying additional objects that should be added to the global scope during linting.parser
- An object containing aparse()
method or aparseForESLint()
method. (default:espree
)parserOptions
- An object specifying additional options that are passed directly to theparse()
orparseForESLint()
method on the parser. The available options are parser-dependent.
linterOptions
- An object containing settings related to the linting process.noInlineConfig
- A Boolean value indicating if inline configuration is allowed.reportUnusedDisableDirectives
- A Boolean value indicating if unused disable and enable directives should be tracked and reported.
processor
- Either an object containingpreprocess()
andpostprocess()
methods or a string indicating the name of a processor inside of a plugin (i.e.,"pluginName/processorName"
).plugins
- An object containing a name-value mapping of plugin names to plugin objects. Whenfiles
is specified, these plugins are only available to the matching files.rules
- An object containing the configured rules. Whenfiles
orignores
are specified, these rule configurations are only available to the matching files.settings
- An object containing name-value pairs of information that should be available to all rules.
::: tip
Patterns specified in files
and ignores
use minimatch
syntax and are evaluated relative to the location of the eslint.config.js
file. If using an alternate config file via the --config
command line option, then all path are evaluated relative to the current working directory.
:::
You can use a combination of files
and ignores
to determine which files should apply the configuration object and which should not. By default, ESLint matches **/*.js
, **/*.cjs
, and **/*.mjs
. Because config objects that don't specify files
or ignores
apply to all files that have been matched by any other configuration object, those config objects apply to any JavaScript files passed to ESLint by default. For example:
// eslint.config.js
export default [
{
rules: {
semi: "error"
}
}
];
With this configuration, the semi
rule is enabled for all files that match the default files in ESLint. So if you pass example.js
to ESLint, the semi
rule is applied. If you pass a non-JavaScript file, like example.txt
, the semi
rule is not applied because there are no other configuration objects that match that filename. (ESLint outputs an error message letting you know that the file was ignored due to missing configuration.)
You can limit which files a configuration object applies to by specifying a combination of files
and ignores
patterns. For example, you may want certain rules to apply only to files in your src
directory:
// eslint.config.js
export default [
{
files: ["src/**/*.js"],
rules: {
semi: "error"
}
}
];
Here, only the JavaScript files in the src
directory have the semi
rule applied. If you run ESLint on files in another directory, this configuration object is skipped. By adding ignores
, you can also remove some of the files in src
from this configuration object:
export default [
{
files: ["src/**/*.js"],
ignores: ["**/*.config.js"],
rules: {
semi: "error"
}
}
];
This configuration object matches all JavaScript files in the src
directory except those that end with .config.js
. You can also use negation patterns in ignores
to exclude files from the ignore patterns, such as:
export default [
{
files: ["src/**/*.js"],
ignores: ["**/*.config.js", "!**/eslint.config.js"],
rules: {
semi: "error"
}
}
];
Here, the configuration object excludes files ending with .config.js
except for eslint.config.js
. That file still has semi
applied.
Non-global ignores
patterns can only match file names. A pattern like "dir-to-exclude/"
will not ignore anything. To ignore everything in a particular directory, a pattern like "dir-to-exclude/**"
should be used instead.
If ignores
is used without files
and there are other keys (such as rules
), then the configuration object applies to all files except the ones specified in ignores
, for example:
export default [
{
ignores: ["**/*.config.js"],
rules: {
semi: "error"
}
}
];
This configuration object applies to all files except those ending with .config.js
. Effectively, this is like having files
set to **/*
. In general, it's a good idea to always include files
if you are specifying ignores
.
If ignores
is used without any other keys in the configuration object, then the patterns act as global ignores. Here's an example:
// eslint.config.js
export default [
{
ignores: [".config/*"]
}
];
This configuration specifies that all of the files in the .config
directory should be ignored. This pattern is added after the default patterns, which are ["**/node_modules/", ".git/"]
.
For more information on configuring rules, see Ignore Files.
When more than one configuration object matches a given filename, the configuration objects are merged with later objects overriding previous objects when there is a conflict. For example:
// eslint.config.js
export default [
{
files: ["**/*.js"],
languageOptions: {
globals: {
MY_CUSTOM_GLOBAL: "readonly"
}
}
},
{
files: ["tests/**/*.js"],
languageOptions: {
globals: {
it: "readonly",
describe: "readonly"
}
}
}
];
Using this configuration, all JavaScript files define a custom global object defined called MY_CUSTOM_GLOBAL
while those JavaScript files in the tests
directory have it
and describe
defined as global objects in addition to MY_CUSTOM_GLOBAL
. For any JavaScript file in the tests directory, both configuration objects are applied, so languageOptions.globals
are merged to create a final result.
Options specific to the linting process can be configured using the linterOptions
object. These effect how linting proceeds and does not affect how the source code of the file is interpreted.
Inline configuration is implemented using an /*eslint*/
comment, such as /*eslint semi: error*/
. You can disallow inline configuration by setting noInlineConfig
to true
. When enabled, all inline configuration is ignored. Here's an example:
// eslint.config.js
export default [
{
files: ["**/*.js"],
linterOptions: {
noInlineConfig: true
}
}
];
Disable and enable directives such as /*eslint-disable*/
, /*eslint-enable*/
and /*eslint-disable-next-line*/
are used to disable ESLint rules around certain portions of code. As code changes, it's possible for these directives to no longer be needed because the code has changed in such a way that the rule is no longer triggered. You can enable reporting of these unused disable directives by setting the reportUnusedDisableDirectives
option to true
, as in this example:
// eslint.config.js
export default [
{
files: ["**/*.js"],
linterOptions: {
reportUnusedDisableDirectives: true
}
}
];
By default, unused disable and enable directives are reported as warnings. You can change this setting using the --report-unused-disable-directives
command line option.
You can configure any number of rules in a configuration object by add a rules
property containing an object with your rule configurations. The names in this object are the names of the rules and the values are the configurations for each of those rules. Here's an example:
// eslint.config.js
export default [
{
rules: {
semi: "error"
}
}
];
This configuration object specifies that the semi
rule should be enabled with a severity of "error"
. You can also provide options to a rule by specifying an array where the first item is the severity and each item after that is an option for the rule. For example, you can switch the semi
rule to disallow semicolons by passing "never"
as an option:
// eslint.config.js
export default [
{
rules: {
semi: ["error", "never"]
}
}
];
Each rule specifies its own options and can be any valid JSON data type. Please check the documentation for the rule you want to configure for more information about its available options.
For more information on configuring rules, see Configure Rules.
ESLint supports adding shared settings into configuration files. When you add a settings
object to a configuration object, it is supplied to every rule. By convention, plugins namespace the settings they are interested in to avoid collisions with others. Plugins can use settings
to specify the information that should be shared across all of their rules. This may be useful if you are adding custom rules and want them to have access to the same information. Here's an example:
// eslint.config.js
export default [
{
settings: {
sharedData: "Hello"
}
}
];
ESLint has two predefined configurations for JavaScript:
js.configs.recommended
- enables the rules that ESLint recommends everyone use to avoid potential errorsjs.configs.all
- enables all of the rules shipped with ESLint
To include these predefined configurations, install the @eslint/js
package and then make any modifications to other properties in subsequent configuration objects:
// eslint.config.js
import js from "@eslint/js";
export default [
js.configs.recommended,
{
rules: {
"no-unused-vars": "warn"
}
}
];
Here, the js.configs.recommended
predefined configuration is applied first and then another configuration object adds the desired configuration for no-unused-vars
.
You can apply these predefined configs to just a subset of files by specifying a config object with a files
key, like this:
// eslint.config.js
import js from "@eslint/js";
export default [
{
files: ["**/src/safe/*.js"],
...js.configs.recommended
}
];
A sharable configuration is an npm package that exports a configuration object or array. This package should be installed as a dependency in your project and then reference from inside of your eslint.config.js
file. For example, to use a shareable configuration named eslint-config-example
, your configuration file would look like this:
// eslint.config.js
import exampleConfig from "eslint-config-example";
export default [
exampleConfig,
// your modifications
{
rules: {
"no-unused-vars": "warn"
}
}
];
In this example, exampleConfig
is an object, so you insert it directly into the configuration array.
Some shareable configurations will export an array instead, in which case you'll need to use the spread operator to insert those items into the configuration array. For example:
// eslint.config.js
import exampleConfigs from "eslint-config-example";
export default [
...exampleConfigs,
// your modifications
{
rules: {
"no-unused-vars": "warn"
}
}
];
Please refer to the documentation for the shareable configuration package you're using to determine whether it is exporting an object or an array.
When ESLint is run on the command line, it first checks the current working directory for eslint.config.js
. If the file is not found, it looks to the next parent directory for the file. This search continues until either the file is found or the root directory is reached.
You can prevent this search for eslint.config.js
by using the -c
or --config
option on the command line to specify an alternate configuration file, such as:
npx eslint --config some-other-file.js **/*.js
In this case, ESLint does not search for eslint.config.js
and instead uses some-other-file.js
.
By default, all configuration objects are applied to all files ending with .js
, .cjs
, and .mjs
. Sometimes, however, a more fine-grained application of configuration settings is necessary. For example, what if you'd like to apply a different configuration to different files in the same directory?