現代的前端專案中，ESLint 應該是一個必備的工具了，而且我認為在寫 code 的時候透過一些 ESLint 規範來避免產生壞味道，是學習設計模式的第一步，畢竟 Linter 規範所去律定的規則，都是從過去的血淚中萃取出來的結晶啊！

使用 ESLint 的好處

透過這些工具搭配來規範寫法，同時也能降低「複雜性」來讓結構更加單純。

另一個重要的好處是降低了不同開發者之間 coding style 的「多樣性」，除了避免因為對語法特性不熟而寫出 Bug 以外，也能讓閱讀、思考程式架構時更加直覺。

ESLint 應該已經被預設在與多的 Starter CLI 工具或框架中了，只需要簡單的設定就可以開始發揮作用，如果專案有調整規則的需求，也都可以在官方文件中找到詳細的設定文件，這邊就不多做贅述。

而現在我就來分享兩個實務上遇過的問題吧。

ESLint VS Formater 的愛恨情仇

這應該是很多人都會遇到的問題吧，用了 Formater 後 ESLint error，auto fix 之後又不敢亂按 Shift + Alt + F ，如果有開 editor.formatOnSave ….

這時候可以考慮選擇 Prettier 作為 Formater 工具，然後搭配 prettier/eslint-plugin-prettier（Vue 的專案可以考慮用 meteorlxy/eslint-plugin-prettier-vue 這套）

只要把這個 plugin 設定到 .eslintrc ，就可以把 .prettierrc 所設定的格式規則給送進 ESLint 檢查跟 fix，只要搭配設定 auto fix 的設定就可以無痛達成 fix error + format 囉。

// .vscode/settings.json
{
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  }
}

錯誤的漸進式修復

另一個常見的問題就是，如果是在專案已經有一定規模之後才引入 ESLint 或是增加新的規則，難免會在專案各地出現大量的報錯。

如果專案僅僅是把 ESLint 當作開發時的檢查，那倒是沒有什麼問題 穩妥LA，搭配著開發維護的進程慢慢的修復就可以了，但如果有透過 CI 來檢查的話呢，可能就會因為這些報錯導致檢查失敗。

這時常見的解決方案有兩種：

1. 透過 .eslintignore 將會報錯的檔案設置排除檢查，或是為先將專案中所有檔案都排除後，透過 ! 來設定某些項目要開啟檢查。
2. 調整 CI 的檢查機制，不進行全域的 ESLint 檢查，而是僅檢查 PR 改動的檔案，確保每次新建或被改動過的檔案，都符合目前的 ESLint 規則。

這兩個方向的話，我個人的經驗是比較推薦第二種，因為隨著專案的開發與維護，慢慢的大多數的檔案都將被修復，而尚未修復的也表示已經較長時間沒有修改了，重要性也偏低。

第一種算是很直覺的解決方式，但這樣的問題是檢查的開啟與否完全手動控制，到了後期會很難追蹤控制修復的狀態，畢竟被關掉檢查的項目，通常就不會有人主動開啟了。

今天聊了我在使用 ESLint 的一些經驗，今天稍微提到的 CI 也是維護專案很重要的工具，明天開始就來分享一下關於 CI 的概念跟我的一些經驗吧。