隨著我們團隊的成長，我們需要更多功能性和美學規則來保持我們的程式碼庫不易出錯和更加一致。幸運的是，我們的後端和前端都使用 JavaScript（具有相同版本的 TypeScript），因此這些變更對我們整個團隊的日常工作產生了很大影響。
我們通常會在所謂的「技術日」（每兩週的星期一）進行此類改進，此時我們可以完成自己選擇的任務。我們嘗試增量地進行這些操作，以避免出現難以維護和審查的持久分支。
最近，我們選擇新增 Unicorn 插件，其中包含數十條 ESlint 規則。一開始可能會讓人感到不知所措，因為它會引發數百個錯誤。幸運的是，我們發現了 eslint-nibble：一個命令列工具，可以幫助透過圖形介面逐一添加規則。
第一步是安裝我們想要應用的新插件。然後，我們現在可以在 .eslintrc.js 中啟用所有規則，而不是逐一啟用規則。最後，我們可以像這樣簡單地使用 eslint-nibble，而不是使用 eslint 一次檢查所有內容：
npx eslint-nibble --fixable-only --no-warnings --cache "./src/**/*.{ts,js,vue}"
然後，我們會看到一張漂亮的圖形，其中顯示了每條失敗的規則以及每個規則的錯誤數：
透過介面選擇規則時，建議我們自動修復它（如果可能）。然後，我們通常在提交之前手動檢查它，以防出現奇怪的情況。
另一個關鍵點是它一次只能修復一個規則，即使一行程式碼包含多個規則錯誤。它使提交成為原子的，因此很容易調試和審查。
如果您在提交之前進行任何其他更改- 例如我們有時需要在更改的行上應用Prettier - 請確保您不要保存並檢查文件，因為它會修復所有其他錯誤與文件中的其他規則相關。正確的方法是僅透過聚焦該行並執行 Quick fix 來手動修復所需的問題，然後使用命令 Fix 而無需格式化 VS Code。
主要優點是輕鬆查看接下來要新增哪些規則最簡單。現在，我們每天都可以選擇修復一條有大量錯誤的規則，或是修復大量只出現幾次的規則。之前，我們都是盲目地一一啟用規則，而沒有事先了解它們的影響。
這也是一個透過閱讀其文件來理解規則本身以及為什麼這樣做更好（或不）的機會，因此我們學習新東西。
我們有時會決定自訂或完全停用規則，因為它不符合我們的需求或程式碼風格。例如，我們決定在某些情況下停用強制使用 Set 的規則：由於 Vue 2 不支援 Map 和 Set 上的反應性，我們認為這可能會引入錯誤或鼓勵開發人員以意想不到的方式使用它。
最後，審閱者可以更輕鬆地一次閱讀有關一條規則的提交。這個工具透過幫助我們不時加入一些 ESlint 規則，讓漸進增強變得輕而易舉。
以上是使用 ESlint Nibble 以乾淨的方式逐步修復大量 ESlint 錯誤的詳細內容。更多資訊請關注PHP中文網其他相關文章！
