前言

我們都知道，javascript 是一門動態弱型別語言，現在平臺、環境等各種因素，很復雜，造成團隊之間的風格，各種各樣，有時候也會出現不可避免的錯誤，造成的排查力度大，團隊維護難，團隊合作差等等，然而ESLint的出現，幫我們團隊解決了代碼統一，風格統一等的問題，讓我們能在編譯中發現代碼錯誤的工具，在團隊協作中，避免低級 Bug，產出風格統一的代碼，從而提高團隊的凝集力，對外讓人感覺很正規的印象，

ESLint

介紹

ESLint是一個開源的專案，由Nicholas C. Zakas（《JavaScript高級程式設計》作者）于2013年六月創建，它的目標是為JavaScript提供一個完全可配置的實用lint工具，

作用

在官網上是這樣說的：“ESLint查找并修復JavaScript代碼中的問題”

• 發現問題

ESLint靜態分析您的代碼以快速發現問題，ESLint內置于大多數文本編輯器中，您可以將ESLint作為持續集成管道的一部分運行，

• 自動修復

ESLint發現的許多問題都可以自動修復，ESLint修復程式可識別語法，因此您不會遇到傳統的查找和替換演算法引入的錯誤，

• 定制

預處理代碼，使用自定義決議器，并撰寫與ESLint內置規則一起使用的自己的規則，您可以自定義ESLint，使其完全按照專案所需的方式作業，

配置方式

配置方式有兩種，一種在目標檔案中使用注釋語法嵌入配置資訊，這種方式只針對當前檔案生效，第二種是全域的，針對整個專案空間或者專案中起作用，所以一般的大廠或者正規的前端團隊，都會定制屬于自己公司或團隊的一些規則配置，

1. 第一種方式，作用域當前檔案，eg:

// 忽略 no-undef 檢查
/* eslint-disable no-undef */
js code

// 忽略 no-new 檢查
/* eslint-disable no-new */
js code

// 設定檢查
/*eslint eqeqeq: off*/ /*eslint eqeqeq: 0*/
js code

• 第二種方式，作用全域，檔案格式，eg:

• JavaScript - use .eslintrc.js 檔案匯出一個包含配置資訊的物件，
• JSON - 使用 .eslintrc.json 定義配置資訊，JSON 檔案中支持 JavaScript 注釋，
• package.json - 在 package.json 檔案中增加一個 eslintConfig 欄位，在該欄位中定義配置資訊，
• .eslintrc

• 多個配置 優先級. eg: .eslintrc.js > .eslintrc.yaml > .eslintrc.yml .eslintrc.json > .eslintrc > package.json

配置引數[主要針對第二種方式]

我們在專案中，都會看到這樣或那樣的組態檔，比如.eslintrc.js，.eslintrc.yaml， .eslintrc.yml， .eslintrc.json， .eslintrc等，還有的寫入到package.json里等等，無論哪一種方式，都是針對專案的一些配置，為了使其統一，其實配置里面是什么樣的引數或者key呢？eg:

module.exports = {
  env: {
    node: true
  },
  globals: {
    var1: "writable",
    ....
  },
  extends: [
    ...
  ],
  rules: {
    ...
  },
  parserOptions: {
    ...
  }
}

• env：你的腳本將要運行在什么環境中,可以是brower、node、es6、mocha等等各種環境,eg:

module.exports = {
  env: {
    node: true,
    browser: true,
    commonjs: true,
    es6: true,
    ...
  },
  ...
}

Tips：在第一種方式中可以這樣使用，eg:

/* eslint-env node, mocha */
js code

• globals: 未在當前檔案中定義的全域變數時，會命中 no-undef 規則，通過 globals 配置指定的全域變數無視 no-undef 規則，eg:

module.exports = {
  ...
  globals: {
    var1: "writable",
    var2: "readonly",
    ....
  },
  ...
}

• extends: 擴展,也就是可以在以后的基礎規則上進行擴展，eg:

module.exports = {
  ...
  extends: {
    // npm 包
    'plugin:vue/essential',
    '@vue/standard',
    // 組態檔的絕對路徑或相對路徑指定
    "./node_modules/coding-standard/eslintDefaults.js",
    "./cicada-eslint-config.js"
    ...
  },
  ...
}

• 一個指定基礎配置來源的字串
• 一個指定基礎配置來源的字串的陣列

往往大多數情況在集成的基礎上并不滿足我們的專案使用要求，往往需要在進行一些額外的配置，比如rules 引數指定的規則可按如下幾種方式進行擴展，eg:

• 啟用基礎配置中沒有規則

• 繼承基礎配置中的規則，改變其錯誤級別，但不改變其附加選項

• 基礎配置: “cicada”: [“error”, “allow-null”]
• 擴展配置: “cicada”: “warn”
• 最終有效配置：“cicada”: [“warn”, “allow-null”]

• 共享配置包，一類匯出 ESLint 配置物件的 npm 包，比如 eslint-config-standard、eslint-config-airbnb 等，共享配置包需要安裝才能使用，配置時可省略報名中的 eslint-config- 前綴，

• eslint:recommended： 啟用 ESLint 內置規則集 的一個子集，

• 覆寫基礎配置中的規則

• 基礎配置：“quotes”: [“error”, “single”, “avoid-escape”]
• 擴展配置：“quotes”: [“error”, “single”]
• 最終有效配置: “quotes”: [“error”, “single”]

還有更多組合和復雜的配置，這里不在一一說明啦！

• plugin: 插件. 第三方定制的規則集合,插件名中的 eslint-plugin- 前綴可以省略，eg:

module.exports = {
  ...
  plugins: {
    '@typescript-eslint',
    ...
  },
  ...
}

• parserOptions: 語法分析器選項，默認使用的語法分析器支持如下幾個選項：ecmaVersion、sourceType、ecmaFeatures，eg：

module.exports = {
  ...
  parserOptions: {
    parser: '@typescript-eslint/parser',
    ecmaVersion: 2019,
    sourceType: 'module',
    ...
  },
  ...
}

Rules 說明

Tips

更多的規則可以參考官網的rules，

結尾語

寫到這里，eslint的一些東西了解的也差不多啦，在前端的領域中，其實挺復雜的，所以我不建議大家去記，只要大家會配置就行啦，再說那么api 怎么也記不過來，高端的程師，借用各種api 檔案，寫出自己的一些配置，這篇文章只是在定制前端規則的介紹，一些基礎的部分，去了解，讓大家有個好的印象，下文張，偏向代碼，直接定制我的cicada(禪思)的eslint 的配置，
定制團隊的eslint rules(二):更新中…