ESLint 配置
ESlint 被設計為完全可配置的，這意味著你可以關閉每一個規則而只運行基本語法驗證，或混合和匹配 ESLint 默認綁定的規則和你的自定義規則，以讓 ESLint 更適合你的項目。有兩種主要的方式來配置 ESLint：
- Configuration Comments - 使用 JavaScript 注釋把配置信息直接嵌入到一個代碼源文件中。
-
Configuration Files - 使用 JavaScript、JSON 或者 YAML 文件為整個目錄和它的子目錄指定配置信息?？梢耘渲靡粋€獨立的 .eslintrc.* 文件，或者直接在
package.json文件里的eslintConfig字段指定配置，ESLint 會查找和自動讀取它們，再者，你可以在命令行運行時指定一個任意的配置文件。
有很多信息可以配置：
- Environments - 指定腳本的運行環境。每種環境都會有一組特定的預定義全局變量。
- Globals - 腳本在執行期間訪問的額外的全局變量。
- Rules - 啟用的規則及其各自的錯誤級別。
所有這些選項讓你可以細粒度地控制 ESLint 如何對待你的代碼。
指定解析器選項
ESLint 允許你指定你想要支持的 JavaScript 語言選項。默認情況下，ESLint 支持 ECMAScript 5 語法。你可以覆蓋該設置，以啟用對 ECMAScript 其它版本和 JSX 的支持。
請注意，對 JSX 語法的支持不用于對 React 的支持。React 使用了一些特定的 ESLint 無法識別的 JSX 語法。如果你正在使用 React 并且想要 React 語義支持，我們推薦你使用 eslint-plugin-react。
同樣的，支持 ES6 語法并不意味著同時支持新的 ES6 全局變量或類型（比如 Set 等新類型）。使用 { "parserOptions": { "ecmaVersion": 6 } } 來啟用 ES6 語法支持；要額外支持新的 ES6 全局變量，使用 { "env":{ "es6": true } }(這個設置會同時自動啟用 ES6 語法支持)。
解析器選項可以在 .eslintrc.* 文件使用 parserOptions 屬性設置?？捎玫倪x項有：
-
ecmaVersion- 默認設置為 5， 你可以使用 3、5、6、7 或 8 來指定你想要使用的 ECMAScript 版本。你也可以用使用年份命名的版本號指定為 2015（同 6），2016（同 7），或 2017（同 8） -
sourceType- 設置為"script"(默認) 或"module"（如果你的代碼是 ECMAScript 模塊)。 -
ecmaFeatures- 這是個對象，表示你想使用的額外的語言特性:globalReturn- 允許在全局作用域下使用return語句impliedStrict- 啟用全局 strict mode (如果ecmaVersion是 5 或更高)jsx- 啟用 JSXexperimentalObjectRestSpread- 啟用實驗性的 object rest/spread properties 支持。(重要：這是一個實驗性的功能,在未來可能會有明顯改變。 建議你寫的規則 不要 依賴該功能，除非當它發生改變時你愿意承擔維護成本。)
.eslintrc.json 文件示例：
{
"parserOptions": {
"ecmaVersion": 6,
"sourceType": "module",
"ecmaFeatures": {
"jsx": true
}
},
"rules": {
"semi": 2
}
}
設置解析器選項能幫助 ESLint 確定什么是解析錯誤，所有語言選項默認都是 false。
指定解析器
ESLint 默認使用Espree作為其解析器，你可以在配置文件中指定一個不同的解析器，只要該解析器符合下列要求：
- 它必須是本地安裝的一個 npm 模塊。
- 它必須有兼容 Esprima 的接口（它必須輸出一個
parse()方法） - 它必須產出兼容 Esprima 的 AST 和 token 對象。
注意，即使滿足這些兼容性要求，也不能保證一個外部解析器可以與 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 來解析 TypeScript 文件（盡管不一定必須通過所有的 ESLint 規則）。
注意，在使用自定義解析器時，為了讓 ESLint 在處理非 ECMAScript 5 特性時正常工作，配置屬性 parserOptions 仍然是必須的。解析器會被傳入 parserOptions，但是不一定會使用它們來決定功能特性的開關。
指定環境
一個“環境”定義了一組預定義的全局變量?？捎玫沫h境包括：
-
browser- 瀏覽器環境中的全局變量。 -
node- Node.js 全局變量和 Node.js 作用域。 -
commonjs- CommonJS 全局變量和 CommonJS 作用域 (一般用于 Browserify/WebPack 打包的只在瀏覽器中運行的代碼)。 -
shared-node-browser- Node 和 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
指定全局變量
當訪問當前源文件內未定義的變量時，no-undef 規則將發出警告。如果你想在一個源文件里使用全局變量，推薦你在 ESLint 中定義這些全局變量，這樣 ESLint 就不會發出警告了。你可以使用注釋或在配置文件中定義全局變量。
要在你的 JavaScript 文件中，用注釋指定全局變量，格式如下：
/* global var1, var2 */
這里定義了兩個全局變量：var1 和 var2。如果你想指定這些變量不應被重寫（只讀），你可以將它們設置為 false：
/* global var1:false, var2:false */
在配置文件里配置全局變量時，使用 globals 指出你要使用的全局變量。將變量設置為 true 將允許變量被重寫，或 false 將不允許被重寫。比如：
{
"globals": {
"var1": true,
"var2": false
}
}
在 YAML 中：
---
globals:
var1: true
var2: false
在這些例子中 var1 允許被重寫，var2 不允許被重寫。
注意： 要啟用no-global-assign規則來禁止對只讀的全局變量進行修改。
配置插件
ESLint 支持使用第三方插件。在使用插件之前，你必須使用 npm 安裝它。
在配置文件里配置插件時，可以使用 plugins 關鍵字來存放插件名字的列表。插件名稱可以省略 eslint-plugin- 前綴。
{
"plugins": [
"plugin1",
"eslint-plugin-plugin2"
]
}
在 YAML 中：
---
plugins:
- plugin1
- eslint-plugin-plugin2
注意：全局安裝的 ESLint 只能使用全局安裝的插件。本地安裝的 ESLint 不僅可以使用本地安裝的插件，也可以使用全局安裝的插件。
配置規則
ESLint 附帶有大量的規則。你可以使用注釋或配置文件修改你項目中要使用的規則。要改變一個規則設置，你必須將規則 ID 設置為下列值之一：
-
"off"或0- 關閉規則 -
"warn"或1- 開啟規則，使用警告級別的錯誤：warn(不會導致程序退出) -
"error"或2- 開啟規則，使用錯誤級別的錯誤：error(當被觸發的時候，程序會退出)
為了在文件注釋里配置規則，使用以下格式的注釋：
/* eslint eqeqeq: "off", curly: "error" */
在這個例子里，eqeqeq 規則被關閉，curly 規則被打開，定義為錯誤級別。你也可以使用對應的數字定義規則嚴重程度：
/* eslint eqeqeq: 0, curly: 2 */
這個例子和上個例子是一樣的，只不過它是用的數字而不是字符串。eqeqeq 規則是關閉的，curly 規則被設置為錯誤級別。
如果一個規則有額外的選項，你可以使用數組字面量指定它們，比如：
/* eslint quotes: ["error", "double"], curly: 2 */
這條注釋為規則 quotes 指定了 “double”選項。數組的第一項總是規則的嚴重程度（數字或字符串）。
還可以使用 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 在內部只使用沒有前綴的名稱去定位規則。
使用行注釋禁用規則
可以在你的文件中使用以下格式的塊注釋來臨時禁止規則出現警告：
/* 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');
在某一特定的行上禁用某個指定的規則：
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');
上面的所有方法同樣適用于插件規則。例如，禁止 eslint-plugin-example 的 rule-name 規則，把插件名（example）和規則名（rule-name）結合為 example/rule-name：
foo(); // eslint-disable-line example/rule-name
注意：為文件的某部分禁用警告的注釋，告訴 ESLint 不要對禁用的代碼報告規則的沖突。ESLint 仍解析整個文件，然而，禁用的代碼仍需要是有效的 JavaScript 語法。
添加分享配置
ESLint 支持在配置文件添加共享設置。你可以添加 settings 對象到配置文件，它將提供給每一個將被執行的規則。如果你想添加的自定義規則而且使它們可以訪問到相同的信息，這將會很有用，并且很容易配置。
在 JSON 中：
{
"settings": {
"sharedData": "Hello"
}
}
在 YAML 中：
---
settings:
sharedData: "Hello"
使用配置文件
有兩種方式可以使用配置文件。第一種是將文件保存到你喜歡的地方，然后將它的位置使用 -c 選項傳遞命令行，比如：
eslint -c myconfig.json myfiletotest.js
第二種方式是通過 .eslintrc.* 和 package.json。ESLint 將自動在要檢測的文件目錄里尋找它們，緊接著是父級目錄，一直到文件系統的根目錄。當你想對一個項目的不同部分的使用不同配置，或當你希望別人能夠直接使用 ESLint，而無需記住要在配置文件中傳遞什么，這種方式就很有用。
每種情況，配置文件都會覆蓋默認設置。
配置文件文件格式
ESLint 支持幾種格式的配置文件：
-
JavaScript - 使用
.eslintrc.js然后輸出一個配置對象。 -
YAML - 使用
.eslintrc.yaml或.eslintrc.yml去定義配置的結構。 -
JSON - 使用
.eslintrc.json去定義配置的結構，ESLint 的 JSON 文件允許 JavaScript 風格的注釋。 -
(不推薦) - 使用
.eslintrc，可以使 JSON 也可以是 YAML。 -
package.json - 在
package.json里創建一個eslintConfig屬性，在那里定義你的配置。
如果同一個目錄下有多個配置文件，ESLint 只會使用一個。優先級順序如下：
.eslintrc.js.eslintrc.yaml.eslintrc.yml.eslintrc.json.eslintrcpackage.json
配置的層級和繼承
當使用 .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
完整的配置層次結構，從最高優先級最低的優先級，如下:
- 行內配置
-
/*eslint-disable*/和/*eslint-enable*/ /*global*//*eslint*//*eslint-env*/
-
- 命令行選項：
--global--rule--env-
-c、--config
- 項目級配置：
- 與要檢測的文件在同一目錄下的
.eslintrc.*或package.json文件 - 繼續在父級目錄尋找
.eslintrc或package.json文件，直到根目錄（包括根目錄）或直到發現一個有"root": true的配置。 - 如果不是（1）到（3）中的任何一種情況，退回到
~/.eslintrc中自定義的默認配置。
- 與要檢測的文件在同一目錄下的
擴展配置文件
一個配置文件可以被基礎配置中的已啟用的規則繼承。
extends 屬性值可以是：
- 在配置中指定的一個字符串
- 字符串數組：每個配置繼承它前面的配置
ESLint 遞歸地進行擴展配置，所以一個基礎的配置也可以有一個 extends 屬性。
rules 屬性可以做下面的任何事情以擴展（或覆蓋）規則：
- 啟用額外的規則
- 改變繼承的規則級別而不改變它的選項：
- 基礎配置：
"eqeqeq": ["error", "allow-null"] - 派生的配置：
"eqeqeq": "warn" - 最后生成的配置：
"eqeqeq": ["warn", "allow-null"]
- 基礎配置：
- 覆蓋基礎配置中的規則的選項
- 基礎配置：
"quotes": ["error", "single", "avoid-escape"] - 派生的配置：
"quotes": ["error", "single"] - 最后生成的配置：
"quotes": ["error", "single"]
- 基礎配置：
使用 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",
}
}
使用可共享的配置包
可共享的配置 是一個 npm 包，它輸出一個配置對象。要確保這個包安裝在 ESLint 能請求到的目錄下。
extends 屬性值可以省略包名的前綴 eslint-config-。
eslint --init 命令可以創建一個配置，這樣你就可以擴展一個流行的風格指南（比如，eslint-config-standard）。
YAML 格式的一個配置文件的例子：
extends: standard
rules:
comma-dangle:
- error
- always
no-empty: warn
使用插件中的配置
插件 是一個 npm 包，通常輸出規則。一些插件也可以輸出一個或多個命名的 配置。要確保這個包安裝在 ESLint 能請求到的目錄下。
plugins 屬性值 可以省略包名的前綴 eslint-plugin-。
extends 屬性值可以由以下組成：
plugin:- 包名 (省略了前綴，比如，
react) /- 配置名稱 (比如
recommended)
JSON 格式的一個配置文件的例子：
{
"plugins": [
"react"
],
"extends": [
"eslint:recommended",
"plugin:react/recommended"
],
"rules": {
"no-set-state": "off"
}
}
使用一個配置文件
extends 屬性值可以是基本配置文件的絕對路徑或相對路徑。
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"
}
}
使用 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",
}
}
基于 glob 模式的配置
有時，你可能需要更精細的配置，比如，如果同一個目錄下的文件需要有不同的配置。因此，你可以在配置中使用 overrides 鍵，它只適用于匹配特定的 glob 模式的文件，使用你在命令行上傳遞的格式 (e.g., app/**/*.test.js)。
怎么工作
- 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 的其他配置相同。覆蓋塊可以包含常規配置中的除了
extends、overrides和root之外的其他任何有效配置選項， - 可以在單個覆蓋塊中提供多個 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.js 和 app/components/barSpec.js 但 不匹配 server/serverSpec.js。如果你在項目根目錄下的 .eslintrc.json 文件中定義了同樣的模式，它將匹配這三個 *Spec 文件。
配置示例
在你的 .eslintrc.json 文件中：
{
"rules": {
"quotes": [ 2, "double" ]
},
"overrides": [
{
"files": [ "bin/*.js", "lib/*.js" ],
"excludedFiles": "*.test.js",
"rules": {
"quotes": [ 2, "single" ]
}
}
]
}
在配置文件中注釋
JSON 和 YAML 配置文件格式都支持注釋 ( package.json 文件不應該包括注釋)。你可以在其他類型的文件中使用 JavaScript 風格的注釋或使用 YAML 風格的注釋，ESLint 會忽略它們。這允許你的配置更加人性化。例如：
{
"env": {
"browser": true
},
"rules": {
// Override our default settings just for this directory
"eqeqeq": "warn",
"strict": "off"
}
}
指定需要檢查的文件擴展名
目前，告訴 ESLint 哪個文件擴展名要檢測的唯一方法是使用 --ext 命令行選項指定一個逗號分隔的擴展名列表。注意，該標記只在與目錄一起使用時有效，如果使用文件名或 glob 模式，它將會被忽略。
忽略文件和目錄
你可以通過在項目根目錄創建一個 .eslintignore 文件告訴 ESLint 去忽略特定的文件和目錄。.eslintignore 文件是一個純文本文件，其中的每一行都是一個 glob 模式表明哪些路徑應該忽略檢測。例如，以下將忽略所有的 JavaScript 文件：
**/*.js
當 ESLint 運行時，在確定哪些文件要檢測之前，它會在當前工作目錄中查找一個 .eslintignore 文件。如果發現了這個文件，當遍歷目錄時，將會應用這些偏好設置。一次只有一個 .eslintignore 文件會被使用，所以，不是當前工作目錄下的 .eslintignore 文件將不會被用到。
Globs 匹配使用 node-ignore，所以大量可用的特性有：
- 以
#開頭的行被當作注釋，不影響忽略模式。 - 路徑是相對于
.eslintignore的位置或當前工作目錄。這也會影響通過--ignore-pattern傳遞的路徑。 - 忽略模式同
.gitignore規范 - 以
!開頭的行是否定模式，它將會重新包含一個之前被忽略的模式。
除了 .eslintignore 文件中的模式，ESLint總是忽略 /node_modules/* 和 /bower_components/* 中的文件。
例如：把下面 .eslintignore 文件放到當前工作目錄里，將忽略 node_modules，bower_components 以及 build/ 目錄下除了 build/index.js 的所有文件。
# /node_modules/* and /bower_components/* ignored by default
# Ignore built files except build/index.js
build/*
!build/index.js
使用備用文件
如果相比于當前工作目錄下 .eslintignore 文件，你更想使用一個不同的文件，你可以在命令行使用 --ignore-path 選項指定它。例如，你可以使用 .jshintignore 文件，因為它有相同的格式：
eslint --ignore-path .jshintignore file.js
你也可以使用你的 .gitignore 文件：
eslint --ignore-path .gitignore file.js
任何文件只要滿足標準忽略文件格式都可以用。記住，指定 --ignore-path 意味著任何現有的 .eslintignore 文件將不被使用。請注意，.eslintignore 中的匹配規則比 .gitignore 中的更嚴格。
在 package.json 中使用 eslintConfig
{
"name": "mypackage",
"version": "0.0.1",
"eslintConfig": {
"env": {
"browser": true,
"node": true
}
},
"eslintIgnore": ["hello.js", "world.js"]
}
忽略文件告警
當您將目錄傳遞給 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 省略使用忽略規則。
