eslint-rspack-plugin 5.0.0 最近正式發佈，這次更新的核心重點在於該套件現在被定義為 Pure ESM Package（純 ESM 模組）。對於初入前端工程領域的開發者來說，這不僅僅是一個版本號的跳轉，更反映了目前 Node.js 生態系在模組系統轉型以及建構工具效能優化上的大趨勢。
理解 Pure ESM 的轉型背景
在 JavaScript 的世界中，模組系統經歷了從 CommonJS（CJS，使用 require 載入）到 ECMAScript Modules（ESM，使用 import 載入）的演進。過去為了相容舊專案，許多套件會同時提供 CJS 和 ESM 兩種版本。然而，維護雙版本會增加開發複雜度，且在某些邊際情況下會導致載入行為不一致。
eslint-rspack-plugin 5.0 決定移除 CJS 版本，完全轉向 Pure ESM。這一舉動是為了與 Rspack 2.0 的核心策略保持一致。Rspack 作為一個追求極速的建構工具，決定全面擁抱 ESM 以簡化模組載入機制，並符合現代 Node.js 的實作慣例。
對開發者的實際影響
如果你使用的是 Node.js 20 或更高版本，這次更新對大多數專案的影響較小。因為新版本的 Node.js 已經支援透過 require 載入部分 ESM 模組，因此大多數透過 JavaScript API 配置插件的專案不需要修改程式碼即可無縫升級。
但在升級過程中，建議開發者檢查自己的工具鏈是否能正常處理 Pure ESM 套件。此外，這也是一個切換到 ESLint Flat Config（扁平化配置）的好時機。在 5.x 版本中，你可以透過 configType 設定為 flat，來使用 ESLint 最新且更具彈性的配置格式。
插件的功能實務與限制
eslint-rspack-plugin 的主要作用是在 Rspack 編譯過程中同步執行 ESLint 檢查。它繼承自 eslint-webpack-plugin，因此配置方式對 Webpack 使用者來說非常親切。
為了平衡開發體驗，它提供了幾個關鍵功能：快取機制（預設開啟，減少重複掃描時間）、多執行緒處理（利用 Thread Pool 分散 lint 任務）以及 lintAllFiles 選項。後者在多環境建構（例如同時有 Client 與 Server 端的 Rsbuild 專案）中尤為重要，因為它可以確保那些不在依賴圖譜中的檔案也能被檢查到。
然而，這裡有一個重要的工程權衡：效能。
為什麼不建議在建構時執行 Lint
雖然在編譯時順便檢查語法很方便，但官方文件明確提醒，將 ESLint 整合進建構流程會顯著增加編譯時間。這就是為什麼 Rsbuild 預設不會在建構時執行 ESLint 的原因。
對於追求極致開發速度的團隊，目前的最佳實踐是將 Lint 過程從建構流程中解耦。你可以選擇使用獨立的指令執行 ESLint，或者轉向 Rstack 生態系推出的新工具 Rslint。
從 ESLint 到 Rslint 的效能飛躍
Rslint 是 Rstack 團隊為了徹底解決 Lint 速度問題而開發的工具。它與傳統 ESLint 的最大不同在於它是用 Go 語言編寫，並基於 typescript-go 運作。
由於 Go 語言在處理並行運算與記憶體管理上的優勢，Rslint 宣稱能提供比傳統 ESLint 快 20 到 40 倍的檢查速度。這意味著開發者不再需要在快速度的建構（Rspack）與慢速度的檢查（ESLint）之間做選擇，而是可以用極低的時間成本獲得即時的語法反饋。
總結與升級建議
如果你目前正在使用 eslint-rspack-plugin 4.x 版本，升級到 5.0 時請注意以下三點：第一，確認 Node.js 版本是否足夠新以支援 Pure ESM；第二，嘗試將 ESLint 配置遷移至 Flat Config 以獲取更好的維護性；第三，評估是否真的需要在建構過程中執行 Lint，若對速度有要求，建議將 Lint 移至獨立腳本或嘗試 Rslint。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。