為什么以及如何在你的項(xiàng)目中使用 ESLint

Npmjs.org 有數(shù)十萬個包，但它們的質(zhì)量不盡相同。檢查直接依賴項(xiàng)的管理情況很重要。如果功能是正確的，那么任何一個缺失的管理實(shí)踐都不應(yīng)該從您的考慮中排除一個包，但是當(dāng)你可以選擇包時，選擇管理良好的包或者準(zhǔn)備好自己維護(hù)包！

我用來評估項(xiàng)目的一種做法是 JavaScript linting。

為什么要對 JavaScript 進(jìn)行 lint？

運(yùn)行良好的項(xiàng)目具有清晰、一致的編碼約定，并具有自動執(zhí)行功能。當(dāng)我審查一個項(xiàng)目時，它的代碼看起來像一個孩子用斧頭和房子的圖片建造的房子，它并沒有激發(fā)代碼功能的信心。

沒有編碼約定也是吸引貢獻(xiàn)的障礙。依賴于一個不歡迎貢獻(xiàn)的項(xiàng)目本身就是一種風(fēng)險(xiǎn)。

除了檢查樣式之外，linter 也是查找某些類型錯誤（例如與變量范圍相關(guān)的錯誤）的絕佳工具。分配給未聲明的變量（這些會泄漏到全局范圍，污染它并可能導(dǎo)致很難找到錯誤）和使用未定義的變量是在 lint 時可檢測到的錯誤示例。

如何配置 ESLint

ESLint 是用于 linting Node.js 包的主要工具，可以配置為強(qiáng)制執(zhí)行多種編碼風(fēng)格。可以定義自己的樣式定義，但在這里我將展示如何使用 StrongLoop 樣式。還有其他的，但是StrongLoop的風(fēng)格平淡無奇（好東西，編碼風(fēng)格不應(yīng)該引起注意），和很多開源Node.js項(xiàng)目中使用的類似。

1. 安裝并保存軟件包依賴項(xiàng)：?npm install --save-dev eslint eslint-config-strongloop?.
2. 通過運(yùn)行設(shè)置 ESLint 以使用 StrongLoop 配置?echo '{"extends": "strongloop"}' > .eslintrc.json?。
3. 確保你有一個.gitignore文件（因此派生文件不會被 linted，只有原始源文件）。如果你沒有，你可以用最少的努力創(chuàng)建一個：?echo node_modules/ >> .gitignore?.請注意，也可以使用特定于 ESLint 的.eslintignore文件，該文件與 .gitignore 具有相同的語法，并且可能具有相同的內(nèi)容。為了避免這種維護(hù)負(fù)擔(dān)，大多數(shù)項(xiàng)目只使用 .gitignore。
4. 使用此設(shè)置，通過將 package.json 更改為pretest腳本，將 ESLint 配置為在測試之前自動運(yùn)行。它應(yīng)該類似于： 

{ ... 
    "scripts": 
    { 
        "pretest": "eslint --ignore-path .gitignore ." 
    } ... 
}

package.json 的確切內(nèi)容取決于您的項(xiàng)目。你必須添加預(yù)測試腳本以使 ESLint 在你的單元測試之前運(yùn)行。當(dāng)你使用 npm 運(yùn)行測試腳本時，它還會運(yùn)行 pretest 和 posttest 腳本（如果存在）。我更喜歡這個，因?yàn)?eslint 通常比我的測試運(yùn)行得快得多，而且 lint 錯誤很容易修復(fù)，但有些人更喜歡在 linter 之前運(yùn)行整個測試套件，在這種情況下，使用 posttest。

5. 提交 ESLint 自動化支持：

git add package.json .gitignore .eslintrc.json 
git commit -m 'Add eslint automation

6. 完成后，運(yùn)行 

linter： npm run pretest

如果你的控制臺充斥著大量錯誤，請不要?dú)怵H！

如何讓現(xiàn)有代碼清理干凈

人們避免使用 ESLint 的一個原因是清理從未被 lint 的代碼感覺就像清理Augean 馬廄。我建議像 Hercules 那樣做：從工具中獲取幫助。

1. ESLint 可以自動修復(fù)許多語法問題。這應(yīng)該是你用來清理源代碼的第一個工具：?./node_modules/.bin/eslint --fix --ignore-path .gitignore .?
2. 如果你有 ESLint 預(yù)測試腳本，你還可以執(zhí)行以下操作：?npm run pretest -- --fix?
3. 有一些類的問題，ESLint不會解決，然而，在這種情況下，你可以用做一次性清理prettier。prettier 最常用作 ESLint 和 auto-formats 源在提交之前的替代品。它在引導(dǎo) ESLint 時也非常有用。像這樣運(yùn)行它： 

npm i prettier ./node_modules/.bin/prettier --single-quote --trailing-comma es5 --print-width 80 --write --no-bracket-spacing **/*.js 

運(yùn)行?eslint --fixand? 后prettier，你應(yīng)該只有很少的剩余警告需要手動清理。雖然 prettier 不像 ESLint 那樣常用，但如果需要，它可以用作 ESLint 的補(bǔ)充（prettier 用于自動格式化，ESLint 用于格式強(qiáng)制和錯誤檢查）。如果由于某種原因您現(xiàn)在沒有時間修復(fù)這些問題，請禁用 ESLint 規(guī)則。自動強(qiáng)制執(zhí)行某些樣式子集比完全不強(qiáng)制要好得多。您可以為特定項(xiàng)目覆蓋一些 StrongLoop 樣式，然后有時間回來清理代碼。

4. 這是放寬?max-len?規(guī)則以允許最多 120 個字符寬的連續(xù)行的示例：

 { 
    "extends": "strongloop", 
    "rules": 
        { 
            "max-len": [2, 120, 8] 
        } 
} 

你可能會發(fā)現(xiàn)你的代碼使用了一致的風(fēng)格，但不是 StrongLoop 的風(fēng)格。如果接近，你可以自定義StrongLoop樣式并發(fā)布為你自己的。如果你的風(fēng)格完全不同，那么編寫和發(fā)布你自己的可重用配置可能是有意義的。

5. 一旦您的代碼干凈利落（使用? npm run pretest? 檢查），提交結(jié)果： 

git commit -a -m 'Project lints clean

自動lint

有兩個級別的自動化：項(xiàng)目范圍的策略和您自己的個人設(shè)置。

就項(xiàng)目范圍的策略而言，因?yàn)?ESLint 被配置為與您的測試一起運(yùn)行，所以沒有什么可做的。除非你沒有為你的項(xiàng)目自動運(yùn)行測試，在這種情況下是時候開始了！

就我自己的個人設(shè)置而言，我更喜歡在我的每個提交上運(yùn)行 ESLint，因此我引入的任何問題都在我的機(jī)器上被 CI 捕獲之前捕獲。我用一個? git pre-commithook?來做這個。

要進(jìn)行設(shè)置，請使用示例鉤子作為基礎(chǔ)：

?cp .git/hooks/pre-commit.sample .git/hooks/pre-commi?t

文件的最后幾行將如下所示：

# If there are whitespace errors, print the offending file names and fail.
exec git diff-index --check --cached $against --

將其更改為如下所示：

set -e
npm run pretest

# If there are whitespace errors, print the offending file names and fail.
exec git diff-index --check --cached $against --

就是這樣，你現(xiàn)在是 eslint 的另一個用戶。