版本

配置文件(已弃用)

您可以将您的 ESLint 项目配置放在一个配置文件中。您可以包含内置规则、您希望如何执行这些规则、带有自定义规则的插件、可共享的配置、您希望规则应用于哪些文件等等。

配置文件格式

ESLint 支持多种格式的配置文件

  • JavaScript - 使用.eslintrc.js并导出一个包含您的配置的对象。
  • JavaScript (ESM) - 当在package.json中指定"type":"module"的 JavaScript 包中运行 ESLint 时,使用.eslintrc.cjs。请注意,ESLint 目前不支持 ESM 配置。
  • YAML - 使用.eslintrc.yaml.eslintrc.yml来定义配置结构。
  • JSON - 使用.eslintrc.json来定义配置结构。ESLint 的 JSON 文件也允许使用 JavaScript 样式的注释。
  • package.json - 在您的package.json文件中创建一个eslintConfig属性并在其中定义您的配置。

如果在同一个目录中有多个配置文件,ESLint 只使用其中一个。优先级顺序如下

  1. .eslintrc.js
  2. .eslintrc.cjs
  3. .eslintrc.yaml
  4. .eslintrc.yml
  5. .eslintrc.json
  6. package.json

使用配置文件

有两种方法可以使用配置文件。

第一种方法是通过.eslintrc.*package.json文件。ESLint 会自动在要 lint 的文件的目录中查找它们,并在连续的父目录中一直向上查找,直到文件系统的根目录(/)、当前用户的 home 目录(~/),或者当指定root: true时。有关此内容的更多详细信息,请参见下面的级联和层次结构。当您希望为项目的不同部分使用不同的配置,或者当您希望其他人能够直接使用 ESLint 而无需记住传递配置文件时,配置文件非常有用。

第二种方法是将文件保存到您想要的任何位置,并将它的位置传递给 CLI,使用--config选项,例如

eslint -c myconfig.json myfiletotest.js

如果您正在使用一个配置文件,并希望 ESLint 忽略任何.eslintrc.*文件,请确保与--config标志一起使用--no-eslintrc

这是一个使用typescript-eslint解析器支持 TypeScript 语法的 JSON 配置文件示例

{
    "root": true,
    "extends": [
        "eslint:recommended",
        "plugin:@typescript-eslint/recommended"
    ],
    "parser": "@typescript-eslint/parser",
    "parserOptions": { "project": ["./tsconfig.json"] },
    "plugins": [
        "@typescript-eslint"
    ],
    "rules": {
        "@typescript-eslint/strict-boolean-expressions": [
            2,
            {
                "allowString" : false,
                "allowNumber" : false
            }
        ]
    },
    "ignorePatterns": ["src/**/*.test.ts", "src/frontend/generated/*"]
}

配置文件中的注释

JSON 和 YAML 配置文件格式都支持注释(package.json文件不应包含注释)。您可以为 JSON 文件使用 JavaScript 样式的注释,为 YAML 文件使用 YAML 样式的注释。ESLint 会安全地忽略配置文件中的注释。这使得您的配置文件更易于阅读。

对于 JavaScript 样式的注释

{
    "env": {
        "browser": true
    },
    "rules": {
        // Override our default settings just for this directory
        "eqeqeq": "warn",
        "strict": "off"
    }
}

对于 YAML 样式的注释

env:
    browser: true
rules:
    # Override default settings
    eqeqeq: warn
    strict: off

添加共享设置

ESLint 支持将共享设置添加到配置文件中。插件使用settings指定应在其所有规则中共享的信息。您可以将settings对象添加到 ESLint 配置文件中,它将被提供给每个执行的规则。如果您正在添加自定义规则并希望它们能够访问相同的信息并易于配置,这可能很有用。

在 JSON 中

{
    "settings": {
        "sharedData": "Hello"
    }
}

在 YAML 中

---
  settings:
    sharedData: "Hello"

级联和层次结构

当使用.eslintrc.*package.json文件进行配置时,您可以利用配置级联。假设您的项目具有以下结构

your-project
├── .eslintrc.json
├── lib
│ └── source.js
└─┬ tests
  ├── .eslintrc.json
  └── test.js

配置级联基于要 lint 的文件的位置。如果在与要 lint 的文件相同的目录中存在.eslintrc文件,则该配置优先。然后,ESLint 会向上搜索目录结构,合并它沿途找到的任何.eslintrc文件,直到到达具有root: true.eslintrc文件或根目录。

同样,如果根目录中存在一个package.json文件,并且它具有eslintConfig字段,则它描述的配置将应用于其下方的所有子目录。但是,tests/目录中的.eslintrc文件描述的配置会覆盖冲突的规范。

your-project
├── package.json
├── lib
│ └── source.js
└─┬ tests
  ├── .eslintrc.json
  └── test.js

如果在同一个目录中找到了.eslintrcpackage.json文件,则.eslintrc优先,并且不使用package.json文件。

默认情况下,ESLint 会在所有父文件夹中一直向上搜索到根目录以查找配置文件。如果您希望所有项目都遵循某个约定,这很有用,但有时会导致意外结果。要将 ESLint 限制到特定项目,请在.eslintrc.*文件或package.json文件的eslintConfig字段中或项目根级别的.eslintrc.*文件中放置"root": true。一旦找到具有"root": true的配置,ESLint 就会停止在父文件夹中搜索。

{
    "root": true
}

在 YAML 中

---
  root: true

例如,考虑projectA,它在lib/目录的.eslintrc文件中设置了"root": true。在这种情况下,在 lint main.js时,将使用lib/中的配置,但不会使用projectA/中的.eslintrc文件。

home
└── user
    └── projectA
        ├── .eslintrc.json  <- Not used
        └── lib
            ├── .eslintrc.json  <- { "root": true }
            └── main.js

完整的配置层次结构,从最高到最低优先级,如下所示

  1. 内联配置
    1. /*eslint-disable*//*eslint-enable*/
    2. /*global*/
    3. /*eslint*/
    4. /*eslint-env*/
  2. 命令行选项(或 CLIEngine 等效项)
    1. --global
    2. --rule
    3. --env
    4. -c--config
  3. 项目级配置
    1. 与要 lint 的文件位于同一目录中的.eslintrc.*package.json文件
    2. 继续在祖先目录中搜索.eslintrc.*package.json文件,直到根目录或找到具有"root": true的配置为止。

请注意,您首选操作系统上当前用户的 home 目录~/)在此上下文中也被视为根目录,并且搜索配置文件也会在此处停止。并且随着从 8.0.0 版本开始删除对个人配置文件的支持,该目录中存在的配置文件将被忽略。

扩展配置文件

扩展后的配置文件可以继承另一个配置文件的所有特性(包括规则、插件和语言选项),并修改所有选项。因此,如下定义了三个配置

  • 基本配置:被扩展的配置。
  • 派生配置:扩展基本配置的配置。
  • 生成的实际配置:将派生配置合并到基本配置的结果。

extends属性值可以是

  • 指定配置的字符串(配置文件的路径、可共享配置的名称、eslint:recommendedeslint:all
  • 字符串数组,其中每个附加配置都扩展了前面的配置

ESLint 递归地扩展配置,因此基本配置也可以具有extends属性。extends属性中的相对路径和可共享配置名称将从其出现的配置文件的位置解析。

可以从配置名称中省略eslint-config-前缀。例如,airbnb将解析为eslint-config-airbnb

rules属性可以执行以下任何操作来扩展(或覆盖)规则集

  • 启用其他规则
  • 更改继承规则的严重性而不更改其选项
    • 基本配置:"eqeqeq": ["error", "allow-null"]
    • 派生配置:"eqeqeq": "warn"
    • 生成的实际配置:"eqeqeq": ["warn", "allow-null"]
  • 覆盖基本配置中规则的选项
    • 基本配置:"quotes": ["error", "single", "avoid-escape"]
    • 派生配置:"quotes": ["error", "single"]
    • 生成的实际配置:"quotes": ["error", "single"]
  • 覆盖基本配置中作为对象给出的规则的选项
    • 基本配置:"max-lines": ["error", { "max": 200, "skipBlankLines": true, "skipComments": true }]
    • 派生配置:"max-lines": ["error", { "max": 100 }]
    • 最终实际配置:"max-lines": ["error", { "max": 100 }],其中skipBlankLinesskipComments 默认值为 false

使用可共享的配置包

一个可共享配置 是一个导出配置对象的 npm 包。确保您已在项目根目录中安装了该包,以便 ESLint 可以引用它。

extends 属性值可以省略包名称的 eslint-config- 前缀。

npm init @eslint/config 命令可以创建一个配置,以便您可以扩展流行的风格指南(例如,eslint-config-standard)。

YAML 格式的配置文件示例

extends: standard
rules:
  comma-dangle:
    - error
    - always
  no-empty: warn

使用 eslint:recommended

extends 属性中使用 "eslint:recommended" 会启用核心规则的一个子集,这些规则会报告常见问题(这些规则在规则页面上用复选标记(推荐)标识)。

这是一个扩展 eslint:recommended 并覆盖一些已设置配置选项的示例

JavaScript 格式的配置文件示例

module.exports = {
    "extends": "eslint:recommended",
    "rules": {
        // enable additional rules
        "indent": ["error", 4],
        "linebreak-style": ["error", "unix"],
        "quotes": ["error", "double"],
        "semi": ["error", "always"],

        // override configuration set by extending "eslint:recommended"
        "no-empty": "warn",
        "no-cond-assign": ["error", "always"],

        // disable rules from base configurations
         "for-direction": "off",
    }
}

使用插件中的配置

一个插件 是一个 npm 包,可以为 ESLint 添加各种扩展。插件可以执行许多功能,包括但不限于添加新的规则和导出可共享配置。确保该包已安装在 ESLint 可以引用它的目录中。

plugins 属性值可以省略包名称的 eslint-plugin- 前缀。

extends 属性值可以包含

  • 插件
  • 包名称(您可以省略前缀,例如,reacteslint-plugin-react 的简写)
  • /
  • 配置名称(例如,recommended

JSON 格式的配置文件示例

{
    "plugins": [
        "react"
    ],
    "extends": [
        "eslint:recommended",
        "plugin:react/recommended"
    ],
    "rules": {
       "react/no-set-state": "off"
    }
}

使用配置文件

extends 属性值可以是到基本配置文件的绝对路径或相对路径。ESLint 相对于使用它的配置文件解析到基本配置文件的相对路径。

JSON 格式的配置文件示例

{
    "extends": [
        "./node_modules/coding-standard/eslintDefaults.js",
        "./node_modules/coding-standard/.eslintrc-es6",
        "./node_modules/coding-standard/.eslintrc-jsx"
    ],
    "rules": {
        "eqeqeq": "warn"
    }
}

使用 "eslint:all"

extends 属性值可以是 "eslint:all",以启用当前安装的 ESLint 版本中的所有核心规则。核心规则集可能会在 ESLint 的任何次要或主要版本中发生变化。

重要:此配置不推荐用于生产环境,因为它会随着每个 ESLint 的次要和主要版本而改变。使用风险自负。

您可能会启用所有核心规则作为探索规则和选项的快捷方式,以便在您决定项目的配置时使用,尤其是在您很少覆盖选项或禁用规则时。规则的默认选项不是 ESLint 的认可(例如,quotes 规则的默认选项并不意味着双引号比单引号更好)。

如果您的配置扩展了 eslint:all,在您升级到更新的 ESLint 主要或次要版本后,请在使用命令行上的 --fix 选项之前查看报告的问题,以便您知道新的可修复规则是否会对代码进行更改。

JavaScript 格式的配置文件示例

module.exports = {
    "extends": "eslint:all",
    "rules": {
        // override default options
        "comma-dangle": ["error", "always"],
        "indent": ["error", 2],
        "no-cond-assign": ["error", "always"],

        // disable now, but enable in the future
        "one-var": "off", // ["error", "never"]

        // disable
        "init-declarations": "off",
        "no-console": "off",
        "no-inline-comments": "off",
    }
}

基于 Glob 模式的配置

v4.1.0+。有时需要更精细的控制配置,例如,如果同一目录中文件的配置必须不同。在这种情况下,您可以在 overrides 键下提供仅适用于与特定 glob 模式匹配的文件的配置,使用与您在命令行上传递的相同格式(例如,app/**/*.test.js)。

覆盖中的 Glob 模式使用minimatch 语法

覆盖是如何工作的?

可以通过使用 overrides 键在配置中基于文件 glob 模式覆盖设置。以下是使用 overrides 键的示例

在您的 .eslintrc.json

{
  "rules": {
    "quotes": ["error", "double"]
  },

  "overrides": [
    {
      "files": ["bin/*.js", "lib/*.js"],
      "excludedFiles": "*.test.js",
      "rules": {
        "quotes": ["error", "single"]
      }
    }
  ]
}

以下是覆盖在配置文件中如何工作

  • 这些模式相对于配置文件的目录应用于文件路径。例如,如果您的配置文件路径为 /Users/john/workspace/any-project/.eslintrc.js,并且您要 lint 的文件路径为 /Users/john/workspace/any-project/lib/util.js,则 .eslintrc.js 中提供的模式将针对相对路径 lib/util.js 执行。
  • Glob 模式覆盖优先于同一配置文件中的常规配置。同一配置中的多个覆盖按顺序应用。也就是说,配置文件中的最后一个覆盖块始终具有最高优先级。
  • Glob 特定配置的工作方式与任何其他 ESLint 配置几乎相同。覆盖块可以包含任何在常规配置中有效的配置选项,但 rootignorePatterns 除外。
    • Glob 特定配置可以具有 extends 设置,但扩展配置中的 root 属性将被忽略。扩展配置中的 ignorePatterns 属性仅用于 Glob 特定配置匹配的文件。
    • 嵌套的 overrides 设置仅在父配置和子配置的 glob 模式都匹配时才应用。当扩展的配置具有 overrides 设置时,情况相同。
  • 可以在单个覆盖块中提供多个 glob 模式。文件必须至少匹配提供的模式之一才能应用配置。
  • 覆盖块还可以指定要排除匹配项的模式。如果文件匹配任何排除的模式,则配置将不适用。

相对 glob 模式

project-root
├── app
│   ├── lib
│   │   ├── foo.js
│   │   ├── fooSpec.js
│   ├── components
│   │   ├── bar.js
│   │   ├── barSpec.js
│   ├── .eslintrc.json
├── server
│   ├── server.js
│   ├── serverSpec.js
├── .eslintrc.json

app/.eslintrc.json 中的配置定义了 glob 模式 **/*Spec.js。此模式相对于 app/.eslintrc.json 的基目录。因此,此模式将匹配 app/lib/fooSpec.jsapp/components/barSpec.js,但匹配 server/serverSpec.js。如果您在 project-root 文件夹内的 .eslintrc.json 文件中定义了相同的模式,它将匹配所有三个 *Spec 文件。

如果通过 --config CLI 选项提供了配置,则配置中的 glob 模式相对于当前工作目录,而不是给定配置的基目录。例如,如果存在 --config configs/.eslintrc.json,则配置中的 glob 模式相对于 . 而不是 ./configs

指定要 lint 的目标文件

如果您使用 CLI 指定了目录(例如,eslint lib),ESLint 会搜索要 lint 的目录中的目标文件。目标文件是 *.js 或与任何 overrides 条目匹配的文件(但排除任何 files* 结尾的条目)。

如果您与目录一起指定了--ext 命令行选项,则目标文件仅是具有指定文件扩展名的文件,而不管 overrides 条目如何。

个人配置文件(已弃用)

⚠️ 此功能已弃用。此功能已在 8.0.0 版本中移除。如果您想继续使用个人配置文件,请使用--config CLI 选项。有关此决定的更多信息,请参阅RFC 28RFC 32

~/ 指的是您首选操作系统上当前用户的 home 目录。此处引用的个人配置文件是 ~/.eslintrc.* 文件,其处理方式目前与其他配置文件不同。

ESLint 如何查找个人配置文件?

如果 eslint 无法在项目中找到任何配置文件,则 eslint 会加载 ~/.eslintrc.* 文件。

如果 eslint 可以在项目中找到配置文件,则 eslint 会忽略 ~/.eslintrc.* 文件,即使它位于项目目录的祖先目录中。

个人配置文件的行为如何?

~/.eslintrc.* 文件的行为类似于常规配置文件,但有一些例外情况

~/.eslintrc.* 文件从 ~/node_modules/ 加载可共享配置和自定义解析器——类似于 require()——位于用户的 home 目录中。请注意,它不会加载全局安装的包。

~/.eslintrc.* 文件默认从 $CWD/node_modules 加载插件,以便唯一地识别插件。如果您想将插件与 ~/.eslintrc.* 文件一起使用,则必须在每个项目中本地安装插件。或者,您可以使用--resolve-plugins-relative-to CLI 选项来更改 ESLint 加载插件的位置。

更改语言