【ESLint】配置 ESLint

目錄

1、配置 ESLint

1.1、指定解析器選項

1.2、指定解析器

1.3、指定處理器

1.4、指定環境

1.5、指定全局變量

1.6、配置插件

1.7、配置規則

1.7.1、註釋配置規則

1.7.2、文件配置規則

1.8、內聯註釋禁用規則 - 一行、塊、整個文件

1.8.1、文件配置禁用規則 - 指定一組文件

1.9、添加共享設置

1.10、使用配置文件

1.11、配置文件格式

1.12、配置文件的級聯與層次結構

1.13、配置文件擴展

1.13.1、使用 "eslint:recommended"

1.13.2、使用可共享的配置包

1.13.3、使用插件中的配置

1.13.4、使用配置文件

1.13.5、使用 "eslint:all"

1.14、基於 Glob 模式的配置

1.14.1、運行方式

1.14.2、glob 模式區別

1.14.3、配置文件示例

1.15、在配置文件中使用註釋

1.16、指定 ESLint 文件的擴展名

1.17、忽略文件或文件夾

1.17.1、.eslintignore

1.17.2 使用備用文件

1.17.3 使用 package.json 的 eslintIgnore 鍵盤

1.17.4 已忽略的文件警告

---

1、配置 ESLint

ESlint 被設計爲完全可配置的，這意味着你可以關閉每一個規則而只運行基本語法驗證，或混合和匹配 ESLint 默認綁定的規則和你的自定義規則，以讓 ESLint 更適合你的項目。有兩種主要的方式來配置 ESLint：

1. Configuration Comments - 使用 JavaScript 註釋把配置信息直接嵌入到一個代碼源文件中。
2. Configuration Files - 使用 JavaScript、JSON 或者 YAML 文件爲整個目錄（處理你的主目錄）和它的子目錄指定配置信息。可以配置一個獨立的 .eslintrc.* 文件，或者直接在 package.json 文件裏的 eslintConfig 字段指定配置，ESLint 會查找和自動讀取它們，再者，你可以在命令行運行時指定一個任意的配置文件。

如果你在你的主目錄（通常 ~/）有一個配置文件，ESLint 只有在無法找到其他配置文件時才使用它。

有很多信息可以配置：

• Environments - 指定腳本的運行環境。每種環境都有一組特定的預定義全局變量。
• Globals - 腳本在執行期間訪問的額外的全局變量。
• Rules - 啓用的規則及其各自的錯誤級別。

所有這些選項讓你可以細粒度地控制 ESLint 如何對待你的代碼。

1.1、指定解析器選項

ESLint 允許你指定你想要支持的 JavaScript 語言選項。默認情況下，ESLint 支持 ECMAScript 5 語法。你可以覆蓋該設置，以啓用對 ECMAScript 其它版本和 JSX 的支持。

請注意，支持 JSX 語法並不等同於支持 React。React 對 ESLint 無法識別的JSX語法應用特定的語義。如果你正在使用 React 並且想要 React 語義支持，我們建議你使用 eslint-plugin-react。

同樣的，支持 ES6 語法並不意味着同時支持新的 ES6 全局變量或類型（比如 Set 等新類型）。對於 ES6 語法，使用 { "parserOptions": { "ecmaVersion": 6 } }；對於新的 ES6 全局變量，使用 { "env":{ "es6": true } }. { "env": { "es6": true } } 自動啓用es6語法，但 { "parserOptions": { "ecmaVersion": 6 } } 不自動啓用es6全局變量。

解析器選項可以在 .eslintrc.* 文件使用 parserOptions 屬性設置。可用的選項有：

• ecmaVersion - 默認設置爲 3，5（默認）， 你可以使用 6、7、8、9 或 10 來指定你想要使用的 ECMAScript 版本。你也可以用使用年份命名的版本號指定爲 2015（同 6），2016（同 7），或 2017（同 8）或 2018（同 9）或 2019 (same as 10)
• sourceType - 設置爲 "script" (默認) 或 "module"（如果你的代碼是 ECMAScript 模塊)。
• ecmaFeatures - 這是個對象，表示你想使用的額外的語言特性:
  • globalReturn - 允許在全局作用域下使用 return 語句
  • impliedStrict - 啓用全局 strict mode (如果 ecmaVersion 是 5 或更高)
  • jsx - 啓用 JSX
  • experimentalObjectRestSpread - 啓用實驗性的 object rest/spread properties 支持。(重要：這是一個實驗性的功能,在未來可能會有明顯改變。 建議你寫的規則 不要 依賴該功能，除非當它發生改變時你願意承擔維護成本。)

.eslintrc.json 文件示例：

{
    "parserOptions": {
        "ecmaVersion": 6,
        "sourceType": "module",
        "ecmaFeatures": {
            "jsx": true
        }
    },
    "rules": {
        "semi": "error"
    }
}

設置解析器選項能幫助 ESLint 確定什麼是解析錯誤，所有語言選項默認都是 false。

1.2、指定解析器

ESLint 默認使用Espree作爲其解析器，你可以在配置文件中指定一個不同的解析器，只要該解析器符合下列要求：

1. 它必須是一個 Node 模塊，可以從它出現的配置文件中加載。通常，這意味着應該使用 npm 單獨安裝解析器包。
2. 它必須符合 parser interface。

注意，即使滿足這些兼容性要求，也不能保證一個外部解析器可以與 ESLint 正常配合工作，ESLint 也不會修復與其它解析器不兼容的相關 bug。

爲了表明使用該 npm 模塊作爲你的解析器，你需要在你的 .eslintrc 文件裏指定 parser 選項。例如，下面的配置指定了 Esprima 作爲解析器：

{
    "parser": "esprima",
    "rules": {
        "semi": "error"
    }
}

以下解析器與 ESLint 兼容：

• Esprima
• Babel-ESLint - 一個對Babel解析器的包裝，使其能夠與 ESLint 兼容。
• @typescript-eslint/parser - 將 TypeScript 轉換成與 estree 兼容的形式，以便在ESLint中使用。

注意，在使用自定義解析器時，爲了讓 ESLint 在處理非 ECMAScript 5 特性時正常工作，配置屬性 parserOptions 仍然是必須的。解析器會被傳入 parserOptions，但是不一定會使用它們來決定功能特性的開關。

1.3、指定處理器

插件可以提供處理器。處理器可以從另一種文件中提取 JavaScript 代碼，然後讓 ESLint 檢測 JavaScript 代碼。或者處理器可以在預處理中轉換 JavaScript 代碼。

若要在配置文件中指定處理器，請使用 processor 鍵，並使用由插件名和處理器名組成的串接字符串加上斜槓。例如，下面的選項啓用插件 a-plugin 提供的處理器 a-processor：

{
    "plugins": ["a-plugin"],
    "processor": "a-plugin/a-processor"
}

要爲特定類型的文件指定處理器，請使用 overrides 鍵和 processor 鍵的組合。例如，下面對 *.md 文件使用處理器 a-plugin/markdown。

{
    "plugins": ["a-plugin"],
    "overrides": [
        {
            "files": ["*.md"],
            "processor": "a-plugin/markdown"
        }
    ]
}

處理器可以生成命名的代碼塊，如 0.js 和 1.js。ESLint 將這樣的命名代碼塊作爲原始文件的子文件處理。你可以在配置的 overrides 部分爲已命名的代碼塊指定附加配置。例如，下面的命令對以 .js 結尾的 markdown 文件中的已命名代碼塊禁用 strict 規則。

{
    "plugins": ["a-plugin"],
    "overrides": [
        {
            "files": ["*.md"],
            "processor": "a-plugin/markdown"
        },
        {
            "files": ["**/*.md/*.js"],
            "rules": {
                "strict": "off"
            }
        }
    ]
}

ESLint 檢查指定代碼塊的文件擴展名，如果 --ext CLI option 不包含文件擴展名，則忽略這些擴展名。如果您想要刪除除 *.js 之外的已命名代碼塊，請確保指定 --ext 選項。

1.4、指定環境

一個環境定義了一組預定義的全局變量。可用的環境包括：

• browser - 瀏覽器環境中的全局變量。
• node - Node.js 全局變量和 Node.js 作用域。
• commonjs - CommonJS 全局變量和 CommonJS 作用域 (用於 Browserify/WebPack 打包的只在瀏覽器中運行的代碼)。
• shared-node-browser - Node.js 和 Browser 通用全局變量。
• es6 - 啓用除了 modules 以外的所有 ECMAScript 6 特性（該選項會自動設置 ecmaVersion 解析器選項爲 6）。
• worker - Web Workers 全局變量。
• amd - 將 require() 和 define() 定義爲像 amd 一樣的全局變量。
• mocha - 添加所有的 Mocha 測試全局變量。
• jasmine - 添加所有的 Jasmine 版本 1.3 和 2.0 的測試全局變量。
• jest - Jest 全局變量。
• phantomjs - PhantomJS 全局變量。
• protractor - Protractor 全局變量。
• qunit - QUnit 全局變量。
• jquery - jQuery 全局變量。
• prototypejs - Prototype.js 全局變量。
• shelljs - ShellJS 全局變量。
• meteor - Meteor 全局變量。
• mongo - MongoDB 全局變量。
• applescript - AppleScript 全局變量。
• nashorn - Java 8 Nashorn 全局變量。
• serviceworker - Service Worker 全局變量。
• atomtest - Atom 測試全局變量。
• embertest - Ember 測試全局變量。
• webextensions - WebExtensions 全局變量。
• greasemonkey - GreaseMonkey 全局變量。

這些環境並不是互斥的，所以你可以同時定義多個。

可以在源文件裏、在配置文件中或使用 命令行 的 --env 選項來指定環境。

要在你的 JavaScript 文件中使用註釋來指定環境，格式如下：

/* eslint-env node, mocha */

該設置啓用了 Node.js 和 Mocha 環境。

要在配置文件裏指定環境，使用 env 關鍵字指定你想啓用的環境，並設置它們爲 true。例如，以下示例啓用了 browser 和 Node.js 的環境：

{
    "env": {
        "browser": true,
        "node": true
    }
}

或在 package.json 文件中：

{
    "name": "mypackage",
    "version": "0.0.1",
    "eslintConfig": {
        "env": {
            "browser": true,
            "node": true
        }
    }
}

在 YAML 文件中：

---
  env:
    browser: true
    node: true

如果你想在一個特定的插件中使用一種環境，確保提前在 plugins 數組裏指定了插件名，然後在 env 配置中不帶前綴的插件名後跟一個 / ，緊隨着環境名。例如：

{
    "plugins": ["example"],
    "env": {
        "example/custom": true
    }
}

或在 package.json 文件中

{
    "name": "mypackage",
    "version": "0.0.1",
    "eslintConfig": {
        "plugins": ["example"],
        "env": {
            "example/custom": true
        }
    }
}

在 YAML 文件中：

---
  plugins:
    - example
  env:
    example/custom: true

1.5、指定全局變量

當訪問當前源文件內未定義的變量時，no-undef 規則將發出警告。如果你想在一個源文件裏使用全局變量，推薦你在 ESLint 中定義這些全局變量，這樣 ESLint 就不會發出警告了。你可以使用註釋或在配置文件中定義全局變量。

要在你的 JavaScript 文件中，用註釋指定全局變量，格式如下：

/* global var1, var2 */

這定義了兩個全局變量，var1 和 var2。如果你想選擇性地指定這些全局變量可以被寫入(而不是隻被讀取)，那麼你可以用一個 "writable" 的標誌來設置它們:

/* global var1:writable, var2:writable */

要在配置文件中配置全局變量，請將 globals 配置屬性設置爲一個對象，該對象包含以你希望使用的每個全局變量。對於每個全局變量鍵，將對應的值設置爲 "writable" 以允許重寫變量，或 "readonly" 不允許重寫變量。例如：

{
    "globals": {
        "var1": "writable",
        "var2": "readonly"
    }
}

在 YAML 中：

---
  globals:
    var1: writable
    var2: readonly

在這些例子中 var1 允許被重寫，var2 不允許被重寫。

可以使用字符串 "off" 禁用全局變量。例如，在大多數 ES2015 全局變量可用但 Promise 不可用的環境中，你可以使用以下配置:

{
    "env": {
        "es6": true
    },
    "globals": {
        "Promise": "off"
    }
}

由於歷史原因，布爾值 false 和字符串值 "readable" 等價於 "readonly"。類似地，布爾值 true 和字符串值 "writeable" 等價於 "writable"。但是，不建議使用舊值。

注意：要啓用no-global-assign規則來禁止對只讀的全局變量進行修改。

1.6、配置插件

ESLint 支持使用第三方插件。在使用插件之前，你必須使用 npm 安裝它。

在配置文件裏配置插件時，可以使用 plugins 關鍵字來存放插件名字的列表。插件名稱可以省略 eslint-plugin- 前綴。

{
    "plugins": [
        "plugin1",
        "eslint-plugin-plugin2"
    ]
}

在 YAML 中：

---
  plugins:
    - plugin1
    - eslint-plugin-plugin2

注意：插件是相對於 ESLint 進程的當前工作目錄解析的。換句話說，ESLint 將加載與用戶通過從項目 Node 交互解釋器運行 ('eslint-plugin-pluginname') 獲得的相同的插件。

1.7、配置規則

ESLint 附帶有大量的規則。你可以使用註釋或配置文件修改你項目中要使用的規則。要改變一個規則設置，你必須將規則 ID 設置爲下列值之一：

• "off" 或 0 - 關閉規則
• "warn" 或 1 - 開啓規則，使用警告級別的錯誤：warn (不會導致程序退出)
• "error" 或 2 - 開啓規則，使用錯誤級別的錯誤：error (當被觸發的時候，程序會退出)

1.7.1、註釋配置規則

爲了在文件註釋裏配置規則，使用以下格式的註釋：

/* eslint eqeqeq: "off", curly: "error" */

在這個例子裏，eqeqeq 規則被關閉，curly 規則被打開，定義爲錯誤級別。你也可以使用對應的數字定義規則嚴重程度：

/* eslint eqeqeq: 0, curly: 2 */

這個例子和上個例子是一樣的，只不過它是用的數字而不是字符串。eqeqeq 規則是關閉的，curly 規則被設置爲錯誤級別。

如果一個規則有額外的選項，你可以使用數組字面量指定它們，比如：

/* eslint quotes: ["error", "double"], curly: 2 */

這條註釋爲規則 quotes 指定了 “double”選項。數組的第一項總是規則的嚴重程度（數字或字符串）。

1.7.2、文件配置規則

還可以使用 rules 連同錯誤級別和任何你想使用的選項，在配置文件中進行規則配置。例如：

{
    "rules": {
        "eqeqeq": "off",
        "curly": "error",
        "quotes": ["error", "double"]
    }
}

在 YAML 中：

---
rules:
  eqeqeq: off
  curly: error
  quotes:
    - error
    - double

配置定義在插件中的一個規則的時候，你必須使用 插件名/規則ID 的形式。比如：

{
    "plugins": [
        "plugin1"
    ],
    "rules": {
        "eqeqeq": "off",
        "curly": "error",
        "quotes": ["error", "double"],
        "plugin1/rule1": "error"
    }
}

在 YAML 中：

---
plugins:
  - plugin1
rules:
  eqeqeq: 0
  curly: error
  quotes:
    - error
    - "double"
  plugin1/rule1: error

在這些配置文件中，規則 plugin1/rule1 表示來自插件 plugin1 的 rule1 規則。你也可以使用這種格式的註釋配置，比如：

/* eslint "plugin1/rule1": "error" */

注意：當指定來自插件的規則時，確保刪除 eslint-plugin- 前綴。ESLint 在內部只使用沒有前綴的名稱去定位規則。

1.8、內聯註釋禁用規則 - 一行、塊、整個文件

可以在你的文件中使用以下格式的塊註釋來臨時禁止規則出現警告：

/* eslint-disable */

alert('foo');

/* eslint-enable */

你也可以對指定的規則啓用或禁用警告:

/* eslint-disable no-alert, no-console */

alert('foo');
console.log('bar');

/* eslint-enable no-alert, no-console */

如果在整個文件範圍內禁止規則出現警告，將 /* eslint-disable */ 塊註釋放在文件頂部：

/* eslint-disable */

alert('foo');

你也可以對整個文件啓用或禁用警告:

/* eslint-disable no-alert */

// Disables no-alert for the rest of the file
alert('foo');

可以在你的文件中使用以下格式的行註釋或塊註釋在某一特定的行上禁用所有規則：

alert('foo'); // eslint-disable-line

// eslint-disable-next-line
alert('foo');

/* eslint-disable-next-line */
alert('foo');

alert('foo'); /* eslint-disable-line */

在某一特定的行上禁用某個指定的規則：

alert('foo'); // eslint-disable-line no-alert

// eslint-disable-next-line no-alert
alert('foo');

alert('foo'); /* eslint-disable-line no-alert */

/* eslint-disable-next-line no-alert */
alert('foo');

在某個特定的行上禁用多個規則：

alert('foo'); // eslint-disable-line no-alert, quotes, semi

// eslint-disable-next-line no-alert, quotes, semi
alert('foo');

alert('foo'); /* eslint-disable-line no-alert, quotes, semi */

/* eslint-disable-next-line no-alert, quotes, semi */
alert('foo');

上面的所有方法同樣適用於插件規則。例如，禁止 eslint-plugin-example 的 rule-name 規則，把插件名（example）和規則名（rule-name）結合爲 example/rule-name：

foo(); // eslint-disable-line example/rule-name
foo(); /* eslint-disable-line example/rule-name */

注意：爲文件的某部分禁用警告的註釋，告訴 ESLint 不要對禁用的代碼報告規則的衝突。ESLint 仍解析整個文件，然而，禁用的代碼仍需要是有效的 JavaScript 語法。

1.8.1、文件配置禁用規則 - 指定一組文件

若要禁用一組文件的配置文件中的規則，請使用 overrides 和 files。例如:

{
  "rules": {...},
  "overrides": [
    {
      "files": ["*-test.js","*.spec.js"],
      "rules": {
        "no-unused-expressions": "off"
      }
    }
  ]
}

1.9、添加共享設置

ESLint 支持在配置文件添加共享設置。你可以添加 settings 對象到配置文件，它將提供給每一個將被執行的規則。如果你想添加的自定義規則而且使它們可以訪問到相同的信息，這將會很有用，並且很容易配置。

在 JSON 中：

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

在 YAML 中：

---
  settings:
    sharedData: "Hello"

1.10、使用配置文件

有兩種方式使用配置文件。

使用配置文件的第一種方式是通過 .eslintrc.* 和 package.json 文件。ESLint 將自動在要檢測的文件目錄裏尋找它們，緊接着是父級目錄，一直到文件系統的根目錄（除非指定 root: true）。當你想對一個項目的不同部分的使用不同配置，或當你希望別人能夠直接使用 ESLint，而無需記住要在配置文件中傳遞什麼，這種方式就很有用。

第二種方式是使用 -c 選項傳遞命令行將文件保持到你喜歡的地方。

eslint -c myconfig.json myfiletotest.js

如果你使用一個配置文件，想要 ESLint 忽略任何 .eslintrc.* 文件，請確保使用 --no-eslintrc 的同時，加上 -c 標記。

每種情況，配置文件都會覆蓋默認設置。

1.11、配置文件格式

ESLint 支持幾種格式的配置文件：

• JavaScript - 使用 .eslintrc.js 然後輸出一個配置對象。
• YAML - 使用 .eslintrc.yaml 或 .eslintrc.yml 去定義配置的結構。
• JSON - 使用 .eslintrc.json 去定義配置的結構，ESLint 的 JSON 文件允許 JavaScript 風格的註釋。
• (棄用) - 使用 .eslintrc，可以使 JSON 也可以是 YAML。
• package.json - 在 package.json 裏創建一個 eslintConfig屬性，在那裏定義你的配置。

如果同一個目錄下有多個配置文件，ESLint 只會使用一個。優先級順序如下：

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

1.12、配置文件的級聯與層次結構

當使用 .eslintrc.* 和 package.json文件的配置時，你可以利用層疊配置。例如，假如你有以下結構：

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

層疊配置使用離要檢測的文件最近的 .eslintrc文件作爲最高優先級，然後纔是父目錄裏的配置文件，等等。當你在這個項目中允許 ESLint 時，lib/ 下面的所有文件將使用項目根目錄裏的 .eslintrc 文件作爲它的配置文件。當 ESLint 遍歷到 test/ 目錄，your-project/.eslintrc 之外，它還會用到 your-project/tests/.eslintrc。所以 your-project/tests/test.js 是基於它的目錄層次結構中的兩個.eslintrc 文件的組合，並且離的最近的一個優先。通過這種方式，你可以有項目級 ESLint 設置，也有覆蓋特定目錄的 ESLint 設置。

同樣的，如果在根目錄的 package.json 文件中有一個 eslintConfig 字段，其中的配置將使用於所有子目錄，但是當 tests 目錄下的 .eslintrc 文件中的規則與之發生衝突時，就會覆蓋它。

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

如果同一目錄下 .eslintrc 和 package.json 同時存在，.eslintrc 優先級高會被使用，package.json 文件將不會被使用。

注意：如果在你的主目錄下有一個自定義的配置文件 (~/.eslintrc) ，如果沒有其它配置文件時它纔會被使用。因爲個人配置將適用於用戶目錄下的所有目錄和文件，包括第三方的代碼，當 ESLint 運行時可能會導致問題。

默認情況下，ESLint 會在所有父級目錄裏尋找配置文件，一直到根目錄。如果你想要你所有項目都遵循一個特定的約定時，這將會很有用，但有時候會導致意想不到的結果。爲了將 ESLint 限制到一個特定的項目，在你項目根目錄下的 package.json 文件或者 .eslintrc.* 文件裏的 eslintConfig 字段下設置 "root": true。ESLint 一旦發現配置文件中有 "root": true，它就會停止在父級目錄中尋找。

{
    "root": true
}

在 YAML 中：

---
  root: true

例如，projectA 的 lib/ 目錄下的 .eslintrc 文件中設置了 "root": true。這種情況下，當檢測 main.js 時，lib/ 下的配置將會被使用，projectA/ 下的 .eslintrc 將不會被使用。

home
└── user
    ├── .eslintrc <- Always skipped if other configs present
    └── projectA
        ├── .eslintrc  <- Not used
        └── lib
            ├── .eslintrc  <- { "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. 與要檢測的文件在同一目錄下的 .eslintrc.* 或 package.json 文件
   2. 繼續在父級目錄尋找 .eslintrc 或 package.json文件，直到根目錄（包括根目錄）或直到發現一個有"root": true的配置。
4. 如果不是（1）到（3）中的任何一種情況，退回到 ~/.eslintrc 中自定義的默認配置。

1.13、配置文件擴展

一個配置文件可以被基礎配置中的已啓用的規則繼承。

extends 屬性值可以是：

• 指定配置的字符串(配置文件的路徑、可共享配置的名稱、eslint:recommended 或 eslint:all)
• 字符串數組：每個配置繼承它前面的配置

ESLint遞歸地擴展配置，因此基本配置也可以具有 extends 屬性。extends 屬性中的相對路徑和可共享配置名從配置文件中出現的位置解析。

rules 屬性可以做下面的任何事情以擴展（或覆蓋）規則：

• 啓用額外的規則
• 改變繼承的規則級別而不改變它的選項：
  • 基礎配置："eqeqeq": ["error", "allow-null"]
  • 派生的配置："eqeqeq": "warn"
  • 最後生成的配置："eqeqeq": ["warn", "allow-null"]
• 覆蓋基礎配置中的規則的選項
  • 基礎配置："quotes": ["error", "single", "avoid-escape"]
  • 派生的配置："quotes": ["error", "single"]
  • 最後生成的配置："quotes": ["error", "single"]

1.13.1、使用 "eslint:recommended"

值爲 "eslint:recommended" 的 extends 屬性啓用一系列核心規則，這些規則報告一些常見問題，在 規則頁面 中被標記爲  。這個推薦的子集只能在 ESLint 主要版本進行更新。

如果你的配置集成了推薦的規則：在你升級到 ESLint 新的主版本之後，在你使用命令行的 --fix 選項之前，檢查一下報告的問題，這樣你就知道一個新的可修復的推薦的規則將更改代碼。

eslint --init 命令可以創建一個配置，這樣你就可以繼承推薦的規則。

JavaScript 格式的一個配置文件的例子：

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

        // override default options for rules from base configurations
        "comma-dangle": ["error", "always"],
        "no-cond-assign": ["error", "always"],

        // disable rules from base configurations
        "no-console": "off",
    }
}

1.13.2、使用可共享的配置包

可共享的配置 是一個 npm 包，它輸出一個配置對象。要確保這個包安裝在 ESLint 能請求到的目錄下。

extends 屬性值可以省略包名的前綴 eslint-config-。

eslint --init 命令可以創建一個配置，這樣你就可以擴展一個流行的風格指南（比如，eslint-config-standard）。

YAML 格式的一個配置文件的例子：

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

1.13.3、使用插件中的配置

插件 是一個 npm 包，通常輸出規則。一些插件也可以輸出一個或多個命名的 配置。要確保這個包安裝在 ESLint 能請求到的目錄下。

plugins 屬性值 可以省略包名的前綴 eslint-plugin-。

extends 屬性值可以由以下組成：

• plugin:
• 包名 (省略了前綴，比如，react)
• /
• 配置名稱 (比如 recommended)

JSON 格式的一個配置文件的例子：

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

1.13.4、使用配置文件

extends 屬性值可以是到基本配置文件的絕對路徑，也可以是相對路徑。ESLint 解析一個相對於使用它的配置文件的基本配置文件的相對路徑。

ESLint 解析基本配置文件的相對路徑相對你你使用的配置文件，除非那個文件在你的主目錄或非 ESLint 安裝目錄的父級目錄。在這些情況下，ESLint 解析基本配合文件的相對路徑相對於被檢測的 項目目錄（尤其是當前工作目錄）。

JSON 格式的一個配置文件的例子：

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

1.13.5、使用 "eslint:all"

extends 屬性值可以是 "eslint:all"，啓用當前安裝的 ESLint 中所有的核心規則。這些規則可以在 ESLint 的任何版本進行更改。

重要：這些配置 不推薦在產品中使用，因爲它隨着 ESLint 版本進行更改。使用的話，請自己承擔風險。

如果你配置 ESLint 升級時自動地啓用新規則，當源碼沒有任何改變時，ESLint 可以報告新問題，因此任何 ESLint 的新的小版本好像有破壞性的更改。

當你決定在一個項目上使用的規則和選項，尤其是如果你很少覆蓋選項或禁用規則，你可能啓用所有核心規則作爲一種快捷方式使用。規則的默認選項並不是 ESLint 推薦的（例如，quotes 規則的默認選項並不意味着雙引號要比單引號好）。

如果你的配置擴展了所有的核心規則：在你升級到一個新的大或小的 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",
    }
}

1.14、基於 Glob 模式的配置

v4.1.0+. 有時，你可能需要更精細的配置，比如，如果同一個目錄下的文件需要有不同的配置。因此，你可以在配置中使用 overrides 鍵，它只適用於匹配特定的 glob 模式的文件，使用你在命令行上傳遞的格式 (e.g., app/**/*.test.js)。

1.14.1、運行方式

• Glob 模式覆蓋只能在配置文件 (.eslintrc.* 或 package.json) 中進行配置。
• 模式應用於相對於配置文件的目錄的文件路徑。 比如，如果你的配置文件的路徑爲 /Users/john/workspace/any-project/.eslintrc.js 而你要檢測的路徑爲 /Users/john/workspace/any-project/lib/util.js，那麼你在 .eslintrc.js 中提供的模式是相對於 ` lib/util.js` 來執行的.
• 在相同的配置文件中，Glob 模式覆蓋比其他常規配置具有更高的優先級。 同一個配置中的多個覆蓋將按順序被應用。也就是說，配置文件中的最後一個覆蓋會有最高優先級。
• 一個 glob 特定的配置幾乎與 ESLint 的其他配置相同。覆蓋塊可以包含常規配置中的除了 root 之外的其他任何有效配置選項，
  • 一個 glob 特定的配置可以有 extends 設置，但是會忽略擴展配置中的 root 屬性。
  • 只有當父配置和子配置的 glob 模式匹配時，纔會應用嵌套的 overrides 設置。當擴展配置具有 overrides 設置時也是如此。
• 可以在單個覆蓋塊中提供多個 glob 模式。一個文件必須匹配至少一個配置中提供的模式。
• 覆蓋塊也可以指定從匹配中排除的模式。如果一個文件匹配了任何一個排除模式，該配置將不再被應用。

1.14.2、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 文件中的配置定義了 **/*Spec.js glob 模式。該模式相對於 app/.eslintrc.json 的基準目錄。因此，該模式匹配 app/lib/fooSpec.js 和 app/components/barSpec.js，但 不匹配 server/serverSpec.js。如果你在項目根目錄的 .eslintrc.json 文件中定義相同的模式，它將匹配所有三個 *Spec 文件。

1.14.3、配置文件示例

在你的 .eslintrc.json 文件中：

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

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

1.15、在配置文件中使用註釋

JSON 和 YAML 配置文件格式都支持註釋 ( package.json 文件不應該包括註釋)。你可以在其他類型的文件中使用 JavaScript 風格的註釋或使用 YAML 風格的註釋，ESLint 會忽略它們。這允許你的配置更加人性化。例如：

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

1.16、指定 ESLint 文件的擴展名

目前，告訴 ESLint 哪個文件擴展名要檢測的唯一方法是使用 --ext 命令行選項指定一個逗號分隔的擴展名列表。注意，該標記只在與目錄一起使用時有效，如果使用文件名或 glob 模式，它將會被忽略。

1.17、忽略文件或文件夾

1.17.1、.eslintignore

你可以通過在項目根目錄創建一個 .eslintignore 文件告訴 ESLint 去忽略特定的文件和目錄。.eslintignore 文件是一個純文本文件，其中的每一行都是一個 glob 模式表明哪些路徑應該忽略檢測。例如，以下將忽略所有的 JavaScript 文件：

**/*.js

當 ESLint 運行時，在確定哪些文件要檢測之前，它會在當前工作目錄中查找一個 .eslintignore 文件。如果發現了這個文件，當遍歷目錄時，將會應用這些偏好設置。一次只有一個 .eslintignore 文件會被使用，所以，不是當前工作目錄下的 .eslintignore 文件將不會被用到。

Globs 匹配使用 node-ignore，所以大量可用的特性有：

• 以 # 開頭的行被當作註釋，不影響忽略模式。
• 路徑是相對於 .eslintignore 的位置或當前工作目錄。通過 --ignore-pattern command 傳遞的路徑也是如此。
• 忽略模式同 .gitignore 規範
• 以 ! 開頭的行是否定模式，它將會重新包含一個之前被忽略的模式。
• 忽略模式依照 .gitignore 規範.

特別值得注意的是，就像 .gitignore 文件，所有用作 .eslintignore 和 --ignore-pattern 模式的路徑必須使用前斜槓作爲它們的路徑分隔符。

# Valid
/root/src/*.js

# Invalid
\root\src\*.js

請參參閱 .gitignore 規範查看有關有效語法的更多示例。

除了 .eslintignore 文件中的模式，ESLint總是忽略 /node_modules/* 和 /bower_components/* 中的文件。

例如：把下面 .eslintignore 文件放到當前工作目錄裏，將忽略項目根目錄下的 node_modules，bower_components 以及 build/ 目錄下除了 build/index.js 的所有文件。

# /node_modules/* and /bower_components/* in the project root are ignored by default

# Ignore built files except build/index.js
build/*
!build/index.js

重要：注意代碼庫的 node_modules 目錄，比如，一個 packages 目錄，默認情況下不會被忽略，需要手動添加到 .eslintignore。

1.17.2 使用備用文件

如果相比於當前工作目錄下 .eslintignore 文件，你更想使用一個不同的文件，你可以在命令行使用 --ignore-path 選項指定它。例如，你可以使用 .jshintignore 文件，因爲它有相同的格式：

eslint --ignore-path .jshintignore file.js

你也可以使用你的 .gitignore 文件：

eslint --ignore-path .gitignore file.js

任何文件只要滿足標準忽略文件格式都可以用。記住，指定 --ignore-path 意味着任何現有的 .eslintignore 文件將不被使用。請注意，.eslintignore 中的匹配規則比 .gitignore 中的更嚴格。

1.17.3 使用 package.json 的 eslintIgnore 鍵盤

如果沒有發現 .eslintignore 文件，也沒有指定替代文件，ESLint 將在 package.json 文件中查找 eslintIgnore 鍵，來檢查要忽略的文件。

{
  "name": "mypackage",
  "version": "0.0.1",
  "eslintConfig": {
      "env": {
          "browser": true,
          "node": true
      }
  },
  "eslintIgnore": ["hello.js", "world.js"]
}

1.17.4 已忽略的文件警告

當你傳遞目錄給 ESLint，文件和目錄是默默被忽略的。如果你傳遞一個指定的文件給 ESLint，你會看到一個警告，表明該文件被跳過了。例如，假如你有一個像這樣的 .eslintignore文件：

foo.js

然後你執行：

eslint foo.js

你將會看到這個警告：

foo.js
  0:0  warning  File ignored because of your .eslintignore file. Use --no-ignore to override.

✖ 1 problem (0 errors, 1 warning)

這種消息出現是因爲 ESLint 不確定你是否想檢測文件。正如這個消息表明的那樣，你可以使用 --no-ignore 覆蓋忽略的規則。