前言

ESLint 提供語法檢查的功能，會檢查出專案中有可能會出錯、語法不正確的地方，也能夠按照個人或團隊的需要設定專屬的 coding style（編碼風格），避免每個人因為自身習慣，打出來的程式都長得不太一樣。

ESLint 能夠作為一個約束性的存在。

前置準備

1. 文中的專案會以前一天的專案架構繼續講解，如果未跟到前一天的進度，可以從 GitHub 上 Clone 下來。
2. 一顆擁有學習熱忱的心。

使用方法

安裝 ESLint

開啟專案後，輸入下方指令安裝 ESLint ：

npm install eslint --save-dev

// global
// npm install eslint --save-dev -g

這裡可以注意，是否需要將 ESLint 安裝在 global 上，如果在 global 中，就可以直接輸入 eslint ... 指令執行，但若是單純裝在專案的 dev 環境，那就只能透過 package.json 的 script 做執行。

昨天我們將 webpack -p 放到 script 上，就是因為 Webpack 也只裝在專案 dev 中而已。

建立 ESLint 設定檔

這個步驟會因為 ESLint 是否安裝在 global 上而有所不同，如果剛剛把 ESLint 安裝在 global 上，就能夠直接執行指令：

eslint --init

如果只裝在 dev 環境，則需要將上面的指令輸入至 package.json 中的 script 裡：

/* package.json 內容 */
/* 除 script 外的都省略 */

"scripts": {
  "build": "webpack -p",
  "eslintInit": "eslint --init"
},

加上後，再使用 npm run eslintInit 執行。

過程中 ESLint 會詢問幾個問題，並根據回答產生設定檔：

如果下載的 ESLint 的版本是 @5.16.0，那問題大概會是：

1. 你想使用 ESLint 來做什麼？
   選擇第三個：檢查語法、找出問題和強制執行編碼風格。
2. 該專案是用什麼方式導入模組？
   選擇第一個：使用 import/export，之後會需要配合 Babel 和 React。
3. 在專案裡用了哪個框架？
   選擇第一個：必須是 React。
4. 想在哪個執行環境下使用？
   選擇第一個：Browser 瀏覽器環境。
5. 該如何定義專案中的編碼風格？
   選擇第一個：依照目前流行的編碼規範。
6. 目前流行的有三個，請問選擇哪一種？
   筆者習慣選擇 Airbnb，但其實三種都可以，不習慣的規則之後也能夠做例外處理。
7. 產生的 config 檔案要用哪種格式？
   一樣是筆者習慣，選擇 JavaScript，看起來比較順眼。

全都回答完後，ESLint 會根據設定，搜尋檢查會需要的依賴套件，詢問是否要幫你 install，例如 React 需要 eslint-plugin-react 和 Airbnb 的 eslint-config-airbnb 等，這個階段直接輸入 Y 便能自動下載。

完成後專案目錄下會多一個 .eslintrc.js：

語法檢查

先打開 package.json，在 script 中多加一行指令，因為打包前的原始碼都放在 src，所以就直接檢查 src 目錄底下所有的 .js 檔案：

/* 除 script 外的都省略 */

"scripts": {
  "build": "webpack -p",
  "eslintInit": "eslint --init",
  "lint": "eslint src/*.js"
},

加完後，在命令提示字元中用 npm run 執行語法檢查：

npm run lint

檢查結果如下：

目前專案中的 src/index.js 裡，有兩個 error 和兩個 waring。而這裡的 error 並不是程式無法執行的錯誤，而是標示出程式的編碼風格不正確的地方。

如上圖，就是第一行的部分有兩個問題，一個是 import/extensions，第二個是 semi，但這些規則剛使用的我們還不熟，因此官網上有提供 規則表 ，可以讓大家對照程式該怎麼修改。

但是也有規則表上沒有紀錄的規則，例如上方的 import/extensions，這時候只要將它拿去 google，基本上都可以找到答案：

rule 設定

如果覺得有些檢查已經有團隊自訂的編碼風格，例如團隊是習慣不加分號的，這時只需在 .eslintrc.js 中的 rule 加上例外規則：

/* rules 外省略 */

rules: {
  // 將關於分號的檢查關掉
  semi: ["error", "never"],
},

再執行一次語法檢查：

會發現原本加上分號的地方都出現錯誤了，這樣也才能知道原來自己的編碼風格有多不一致。

最後如果團隊認為某些檢查是沒有必要的，則是透過配置 off 來關掉對該規則的檢查：

/* rules 外省略 */

rules: {
  // 將關於分號的檢查關掉
  semi: ["off"],
},

再檢查一次，就不會出現關於 semi 的錯誤了：

Visual Studio Code

如果各位和筆者一樣，也使用 Visual Studio Code 開發的話，可以從擴充套件上下載 ESLint 的檢查小幫手：

有了它就不需要再另外用 eslint 做檢查，在 coding 的時候，就會同步將不符合編碼風格的地方劃上紅線：

這樣就不用反覆執行 ESLint 確認了，不過要注意，在安裝完後，記得要重開 IDE，這樣擴充元件才會執行。

文章中的原始碼都會整理在 GitHub 上。

結尾

本文簡單描述了 ESLint 的配置教學，就像文章中說的，有時候可能會認為自己的編碼風格是乾淨的，但是檢查後才發現原來有那麼多不一致的地方，因此透過 ESLint，就能夠慢慢養成習慣，寫出風格一致的程式碼。

如果文章中有任何問題，再麻煩大家留言告訴我，謝謝！