這篇文章主要講解了“怎么在項目中使用ESLint”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“怎么在項目中使用ESLint”吧！
運行良好的項目具有清晰、一致的編碼約定，并具有自動執行功能。當我審查一個項目時，它的代碼看起來像一個孩子用斧頭和房子的圖片建造的房子，它并沒有激發代碼功能的信心。
沒有編碼約定也是吸引貢獻的障礙。依賴于一個不歡迎貢獻的項目本身就是一種風險。
除了檢查樣式之外，linter 也是查找某些類型錯誤（例如與變量范圍相關的錯誤）的絕佳工具。分配給未聲明的變量（這些會泄漏到全局范圍，污染它并可能導致很難找到錯誤）和使用未定義的變量是在 lint 時可檢測到的錯誤示例。
ESLint 是用于 linting Node.js 包的主要工具，可以配置為強制執行多種編碼風格?？梢远x自己的樣式定義，但在這里我將展示如何使用 StrongLoop 樣式。還有其他的，但是StrongLoop的風格平淡無奇（好東西，編碼風格不應該引起注意），和很多開源Node.js項目中使用的類似。
安裝并保存軟件包依賴項：npm install --save-dev eslint eslint-config-strongloop.
通過運行設置 ESLint 以使用 StrongLoop 配置echo '{"extends": "strongloop"}' > .eslintrc.json。
確保你有一個.gitignore文件（因此派生文件不會被 linted，只有原始源文件）。如果你沒有，你可以用最少的努力創建一個：echo node_modules/ >> .gitignore.請注意，也可以使用特定于 ESLint 的.eslintignore文件，該文件與 .gitignore 具有相同的語法，并且可能具有相同的內容。為了避免這種維護負擔，大多數項目只使用 .gitignore。
使用此設置，通過將 package.json 更改為pretest腳本，將 ESLint 配置為在測試之前自動運行。它應該類似于：
{ ...
"scripts":
{
"pretest": "eslint --ignore-path .gitignore ."
} ...
}package.json 的確切內容取決于您的項目。你必須添加預測試腳本以使 ESLint 在你的單元測試之前運行。當你使用 npm 運行測試腳本時，它還會運行 pretest 和 posttest 腳本（如果存在）。我更喜歡這個，因為 eslint 通常比我的測試運行得快得多，而且 lint 錯誤很容易修復，但有些人更喜歡在 linter 之前運行整個測試套件，在這種情況下，使用 posttest。
提交 ESLint 自動化支持：
git add package.json .gitignore .eslintrc.json
git commit -m 'Add eslint automation完成后，運行
linter： npm run pretest如果你的控制臺充斥著大量錯誤，請不要氣餒！
人們避免使用 ESLint 的一個原因是清理從未被 lint 的代碼感覺就像清理Augean 馬廄。我建議像 Hercules 那樣做：從工具中獲取幫助。
ESLint 可以自動修復許多語法問題。這應該是你用來清理源代碼的第一個工具：./node_modules/.bin/eslint --fix --ignore-path .gitignore .
如果你有 ESLint 預測試腳本，你還可以執行以下操作：npm run pretest -- --fix
有一些類的問題，ESLint不會解決，然而，在這種情況下，你可以用做一次性清理prettier。prettier 最常用作 ESLint 和 auto-formats 源在提交之前的替代品。它在引導 ESLint 時也非常有用。像這樣運行它：
npm i prettier ./node_modules/.bin/prettier --single-quote --trailing-comma es5 --print-width 80 --write --no-bracket-spacing **/*.js運行eslint --fixand 后prettier，你應該只有很少的剩余警告需要手動清理。雖然 prettier 不像 ESLint 那樣常用，但如果需要，它可以用作 ESLint 的補充（prettier 用于自動格式化，ESLint 用于格式強制和錯誤檢查）。如果由于某種原因您現在沒有時間修復這些問題，請禁用 ESLint 規則。自動強制執行某些樣式子集比完全不強制要好得多。您可以為特定項目覆蓋一些 StrongLoop 樣式，然后有時間回來清理代碼。
這是放寬max-len規則以允許最多 120 個字符寬的連續行的示例：
{
"extends": "strongloop",
"rules":
{
"max-len": [2, 120, 8]
}
}你可能會發現你的代碼使用了一致的風格，但不是 StrongLoop 的風格。如果接近，你可以自定義StrongLoop樣式并發布為你自己的。如果你的風格完全不同，那么編寫和發布你自己的可重用配置可能是有意義的。
一旦您的代碼干凈利落（使用 npm run pretest 檢查），提交結果：
git commit -a -m 'Project lints clean有兩個級別的自動化：項目范圍的策略和您自己的個人設置。
就項目范圍的策略而言，因為 ESLint 被配置為與您的測試一起運行，所以沒有什么可做的。除非你沒有為你的項目自動運行測試，在這種情況下是時候開始了！
就我自己的個人設置而言，我更喜歡在我的每個提交上運行 ESLint，因此我引入的任何問題都在我的機器上被 CI 捕獲之前捕獲。我用一個 git pre-commithook來做這個。
要進行設置，請使用示例鉤子作為基礎：
cp .git/hooks/pre-commit.sample .git/hooks/pre-commit
文件的最后幾行將如下所示：
# 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 --
就是這樣，你現在是 eslint 的另一個用戶。
感謝各位的閱讀，以上就是“怎么在項目中使用ESLint”的內容了，經過本文的學習后，相信大家對怎么在項目中使用ESLint這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
