深入了解 ESLint

一個協助開發者維護程式碼品質的好工具

目前 ESLint 中的規則可大致分為兩類：格式化規則與程式品質規則。根據 Prettier 官網的「 Prettier vs. Linters 」文件指出，ESLint 中的格式化規則其實可以完全交由 Prettier 處理。因此，ESLint 自 v8.53.0 起也正式棄用格式化規則，代表不再建議使用 ESLint 來處理格式。

換句話說，我們可以將程式碼的排版與格式交給 Prettier，讓 ESLint 專注於程式碼品質檢查，兩者搭配使用才能發揮最大的效益。

為什麼需要 ESLint ?

在多人協作的開發環境中，每個人撰寫程式碼的風格可能都不太一樣。這會導致程式碼可讀性降低、維護成本增加，甚至可能埋下潛在的 bug。因此，維持一致的程式碼風格非常重要。 ESLint 不只是用來統一程式碼風格，更重要的是，它能幫助開發者在開發階段就發現潛在的錯誤。例如：

• no-undef：可以偵測並防止使用未定義的變數，避免因打錯變數名稱導致錯誤。
• eqeqeq：強制使用 === 和 !==，避免 == 所帶來的隱式型別轉換問題，減少預期外的行為發生。

除了上述規則，ESLint 還提供了大量的檢查項目，協助開發者提升程式碼品質、維持一致性，並減少除錯時間。

安裝及設定 ESLint

ESLint v9 起改用了新的設定格式，建議直接執行以下指令：

npm init @eslint/config@latest // 請記得先 npm init

照著提示回答問題，會自動安裝所需套件並建立設定檔。完成後，就可以用以下指令檢查程式碼：

npx eslint yourfile.js

整合開發工具（建議一起做）

VSCode：安裝 ESLint 擴充套件，並在 settings.json 加入以下設定：

"editor.codeActionsOnSave": {
  "source.fixAll.eslint": "explicit"
} // 手動儲存時，ESLint 執行自動修正

Prettier : ESLint 設定檔的 extends 加上prettier ，關閉 ESLint 中會與 Prettier 會有衝突的規則

npm install --save-dev eslint-config-prettier

Git pre-commit 自動檢查 : 安裝 husky 與 lint-staged 。記得到 ./husky/_/pre-commit 刪除 . "$(dirname "$0")/_/husky.sh" 並加上 npx lint-staged

npm install --save-dev husky lint-staged
npx husky install

在 package.json 中加入：

"lint-staged": {
  "**/*.{js,ts,jsx,tsx}": ["eslint --fix"]
}

結論

我有位老師曾說過：「會跟你深入討論 ESLint 的人，通常都是主管等級的開發者。」所以，如果你未來想往上爬、成為領導型的開發者，我會非常推薦你深入學習這個工具，因為這絕對是百利而無一害的投資。 這篇文章的目的是想讓剛接觸 ESLint 的人，在五分鐘內完成基本設定，不過，ESLint 其實還有很多可以深入學習的地方。舉例來說，我們公司目前是以 Airbnb 的設定為基礎，但也針對一些規則設定了 off。這些調整通常是早期為了開發方便所做的權宜之計，但其實有些規則應該被啟用才對。 此外，有些規則其實可以根據自己專案的需求進一步客製化。這也是我目前正在學習的方向：透過閱讀原始碼，了解 Airbnb 規則套件設定了哪些規則，接著查閱官方文件，理解這些規則的檢查邏輯，最後再評估我們公司的專案，判斷哪些規則可以直接沿用，哪些則需要調整。

參考資源 https://prettier.io/docs/comparison

https://eslint.org/blog/2023/10/deprecating-formatting-rules/