Oxlint 會取代 Eslint 嗎？
最近，一個基于 Rust 的代碼檢查工具 Oxlint 在國外前端社區引起了熱議，許多專家對其給予了高度評價。那么，相比于它的大哥 Eslint，Oxlint 有哪些優勢？它會在未來取代 Eslint 嗎？本文將討論這個話題。
Oxc 和 Oxlint
Oxlint 是 Oxc 項目下的一個產品，Oxc 是一個用 Rust 實現的前端工具鏈集合，包括：
- Linter：即 Oxlint，可與 Eslint 相媲美，是本文的主角
- Parser：即 oxc_parser，用于解析 .js(x) 和 .ts(x)，可與 swc 媲美。基準測試聲稱其速度是 swc 的兩倍
圖片
- Resolver：解析 ESM 和 CJS 文件的路徑，基準測試顯示其速度比 webpack/enhanced-resolve 快 28 倍
- Formatter：基準測試對比 Prettier，尚未公布
- Transpiler：對比 Babel 用于將高級語法轉為低級語法，尚未公布
- Minifier：代碼壓縮工具，尚未公布
除了與 Oxc 具有相同設計理念的工具（所有工具鏈工具均基于 Rust 開發）之外，還有 Biome 和 Ruff：
- Biome：其前身是由 Babel 作者 Sebastian McKenzie 開發的 Rome。目標語言是 JS
- Ruff：目標語言是 Python
Oxlint 介紹
Oxlint 引發熱議的主要原因是其爆炸性的性能。
圖片
我使用 Apple M1 Pro 32G 運行一個包含約 50 個文件的小項目，僅用了 18ms，官方聲稱其基準測試中比 Eslint 快 50-100 倍的說法并非虛言。
圖片
當然，除了性能優勢外，Oxlint 與 Eslint 還有許多不同之處。接下來，我們將從三個方面比較 Oxlint 和 Eslint：
易用性
Eslint 誕生于 2013 年。相比于競爭對手（如 JSHint），其最大的優勢在于提供大量可選規則，并在某些場景下可以自動修復不符合規則的代碼。
然而，隨著時間推移，這一優勢逐漸變成劣勢——開發者不再需要大量自定義規則，而是需要基于最佳實踐的開箱即用規則集。許多新產品正是基于這一概念而誕生的，如：
- Prettier：僅檢查和格式化代碼風格
- eslint-plugin-antfu：Antfu 自定義規則集的版本
Oxlint 借鑒了上述產品的優勢，提供了一套開箱即用的默認規則。這套規則主要關注代碼的正確性（如語法錯誤、冗余代碼和容易引起誤解的語法），而不是優化代碼細節（如語法性能或風格）。
因此，只需要在項目中執行以下命令即可滿足常規驗證：
npx oxlint@latest在易用性方面，Oxlint 遠勝于 Eslint。
可讀性診斷
當代碼檢查工具檢測到問題時，它會向開發者提供相關信息。Eslint 提供的信息通常很簡短，只告訴你錯誤的原因。例如，對于以下代碼：
let a;通過信息 "a is defined but never used"，我們可以知道錯誤的原因是變量 a 被定義但未使用。
然而，如果是更復雜的規則，簡短的信息可能無法直觀地表達錯誤發生的位置和解決方法。許多時候，我們仍需查看規則文檔，了解該規則的具體含義，然后結合錯誤代碼進行分析。
相比之下，Oxlint 提供的信息更加直觀和準確。例如，執行以下代碼后，會得到一個倍增數的數組：
const numbers = [1, 2, 3, 4, 5];
const result = numbers.reduce((accumulator, current) => {
return [...accumulator, current * 2];
}, []);
// [ 2, 4, 6, 8, 10 ]
console.log(result);每次 reduce 回調執行時，數組都會擴展，當數組很長時，這會導致性能問題。
針對這個問題，Oxlint 的信息包括三部分：
- 錯誤原因
- 錯誤具體發生的位置
- 解決方法
圖片
通過查看代碼中的哪個 reduce 操作（紫色字體）和哪個擴展操作（青色字體），我們可以識別問題。
雖然有些人可能會說，如果項目很大，閱讀如此詳細的 lint 信息是一種頭疼的事。
但我們需要知道——你可以提供它，但我不一定要使用它，不使用它與不能提供它是完全不同的概念。
在診斷可讀性方面，Oxlint 優于 Eslint。
參與成本
參與成本指的是開發者自定義規則的成本。Oxlint 是用 Rust 編寫的，如果開發者需要用 Rust 來編寫自定義規則，成本會很高。相比之下，Eslint 的規則是用 JS 編寫的，成本要低得多。
Oxlint 嘗試從兩個方面解決這個問題：
不需要自己編寫，官方已經編寫了常用規則。
截至本文撰寫時，官方已經實現了大約 200 多條規則。從規則的名稱可以看出，這些規則是從各種常見庫的最佳實踐中提取出來的，例如：
- jest: no-confusing-set-timeout
- react: jsx-no-duplicate-props
- eslint: default-case-last
- typescript: no-unnecessary-type-constraint
實現專門為編寫規則設計的 DSL。
Oxlint 正在研發一種專門用于編寫規則的 DSL。至于這個 DSL 何時發布以及效果如何，目前尚不清楚。
從參與成本的角度來看，Eslint 完全勝出。
Oxlint 會取代 Eslint 嗎？
根據已知情況，Oxlint 規則參與成本高于 Eslint。只要這個問題沒有解決，Eslint 支持的一些規則 Oxlint 就無法支持。因此，短期內完全取代 Eslint 是不現實的。
然而，就像 Vite 相對于 Webpack，前者并未實現后者的所有功能。但只要滿足 90% 開發者的常見需求，并提供更好的體驗，就能吸引大多數 Webpack 用戶。
Oxlint 也是如此——它建議開發者先運行 Oxlint，然后在 lint-staged 或 CI 設置中運行 ESLint。這樣，大多數常見問題在到達 ESLint 之前就被 Oxlint 阻止了。
這種方法可以顯著提高 lint 過程的速度，并且學習曲線很低。因此，它很可能在開發者中迅速流行。
當這種方法變得流行時，隨著 Oxlint 規則覆蓋范圍的增加，它將逐漸替代 Eslint 最常見的 90% 需求。
到那時，會出現 Oxlint 為主，Eslint 為輔（處理少數特殊規則）的情況。
從這個角度來看，Oxlint 有很大的勝算。
盡管 Oxlint 前景光明，但它目前還有一些缺點，例如：
框架語法：Oxlint 原生支持 js(x) 和 ts(x)，但不支持 Svelte 或 Vue 模板語法。
vscode 插件仍不穩定，有 bug。例如，在下面的代碼中，警告應該在第 1 行和第 3 行，但第 2 行也被標記了。
圖片
我相信，隨著開發團隊的持續投入和社區生態系統的形成，Oxlint 及其底層 Oxc 將擁有光明的未來。
