最近，一個(gè)基于 Rust 的代碼檢查工具 Oxlint 在國外前端社區(qū)引起了熱議，許多專家對其給予了高度評價(jià)。那么，相比于它的大哥 Eslint，Oxlint 有哪些優(yōu)勢？它會在未來取代 Eslint 嗎？本文將討論這個(gè)話題。

Oxc 和 Oxlint

Oxlint 是 Oxc 項(xiàng)目下的一個(gè)產(chǎn)品，Oxc 是一個(gè)用 Rust 實(shí)現(xiàn)的前端工具鏈集合，包括：

• Linter：即 Oxlint，可與 Eslint 相媲美，是本文的主角
• Parser：即 oxc_parser，用于解析 .js(x) 和 .ts(x)，可與 swc 媲美?；鶞?zhǔn)測試聲稱其速度是 swc 的兩倍

圖片

• Resolver：解析 ESM 和 CJS 文件的路徑，基準(zhǔn)測試顯示其速度比 webpack/enhanced-resolve 快 28 倍
• Formatter：基準(zhǔn)測試對比 Prettier，尚未公布
• Transpiler：對比 Babel 用于將高級語法轉(zhuǎn)為低級語法，尚未公布
• Minifier：代碼壓縮工具，尚未公布

除了與 Oxc 具有相同設(shè)計(jì)理念的工具（所有工具鏈工具均基于 Rust 開發(fā)）之外，還有 Biome 和 Ruff：

• Biome：其前身是由 Babel 作者 Sebastian McKenzie 開發(fā)的 Rome。目標(biāo)語言是 JS
• Ruff：目標(biāo)語言是 Python

Oxlint 介紹

Oxlint 引發(fā)熱議的主要原因是其爆炸性的性能。

圖片

我使用 Apple M1 Pro 32G 運(yùn)行一個(gè)包含約 50 個(gè)文件的小項(xiàng)目，僅用了 18ms，官方聲稱其基準(zhǔn)測試中比 Eslint 快 50-100 倍的說法并非虛言。

圖片

當(dāng)然，除了性能優(yōu)勢外，Oxlint 與 Eslint 還有許多不同之處。接下來，我們將從三個(gè)方面比較 Oxlint 和 Eslint：

易用性

Eslint 誕生于 2013 年。相比于競爭對手（如 JSHint），其最大的優(yōu)勢在于提供大量可選規(guī)則，并在某些場景下可以自動修復(fù)不符合規(guī)則的代碼。

然而，隨著時(shí)間推移，這一優(yōu)勢逐漸變成劣勢——開發(fā)者不再需要大量自定義規(guī)則，而是需要基于最佳實(shí)踐的開箱即用規(guī)則集。許多新產(chǎn)品正是基于這一概念而誕生的，如：

• Prettier：僅檢查和格式化代碼風(fēng)格
• eslint-plugin-antfu：Antfu 自定義規(guī)則集的版本

Oxlint 借鑒了上述產(chǎn)品的優(yōu)勢，提供了一套開箱即用的默認(rèn)規(guī)則。這套規(guī)則主要關(guān)注代碼的正確性（如語法錯(cuò)誤、冗余代碼和容易引起誤解的語法），而不是優(yōu)化代碼細(xì)節(jié)（如語法性能或風(fēng)格）。

因此，只需要在項(xiàng)目中執(zhí)行以下命令即可滿足常規(guī)驗(yàn)證：

npx oxlint@latest

在易用性方面，Oxlint 遠(yuǎn)勝于 Eslint。

可讀性診斷

當(dāng)代碼檢查工具檢測到問題時(shí)，它會向開發(fā)者提供相關(guān)信息。Eslint 提供的信息通常很簡短，只告訴你錯(cuò)誤的原因。例如，對于以下代碼：

let a;

通過信息 "a is defined but never used"，我們可以知道錯(cuò)誤的原因是變量 a 被定義但未使用。

然而，如果是更復(fù)雜的規(guī)則，簡短的信息可能無法直觀地表達(dá)錯(cuò)誤發(fā)生的位置和解決方法。許多時(shí)候，我們?nèi)孕璨榭匆?guī)則文檔，了解該規(guī)則的具體含義，然后結(jié)合錯(cuò)誤代碼進(jìn)行分析。

相比之下，Oxlint 提供的信息更加直觀和準(zhǔn)確。例如，執(zhí)行以下代碼后，會得到一個(gè)倍增數(shù)的數(shù)組：

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 回調(diào)執(zhí)行時(shí)，數(shù)組都會擴(kuò)展，當(dāng)數(shù)組很長時(shí)，這會導(dǎo)致性能問題。

針對這個(gè)問題，Oxlint 的信息包括三部分：

• 錯(cuò)誤原因
• 錯(cuò)誤具體發(fā)生的位置
• 解決方法

圖片

通過查看代碼中的哪個(gè) reduce 操作（紫色字體）和哪個(gè)擴(kuò)展操作（青色字體），我們可以識別問題。

雖然有些人可能會說，如果項(xiàng)目很大，閱讀如此詳細(xì)的 lint 信息是一種頭疼的事。

但我們需要知道——你可以提供它，但我不一定要使用它，不使用它與不能提供它是完全不同的概念。

在診斷可讀性方面，Oxlint 優(yōu)于 Eslint。

參與成本

參與成本指的是開發(fā)者自定義規(guī)則的成本。Oxlint 是用 Rust 編寫的，如果開發(fā)者需要用 Rust 來編寫自定義規(guī)則，成本會很高。相比之下，Eslint 的規(guī)則是用 JS 編寫的，成本要低得多。

Oxlint 嘗試從兩個(gè)方面解決這個(gè)問題：

不需要自己編寫，官方已經(jīng)編寫了常用規(guī)則。

截至本文撰寫時(shí)，官方已經(jīng)實(shí)現(xiàn)了大約 200 多條規(guī)則。從規(guī)則的名稱可以看出，這些規(guī)則是從各種常見庫的最佳實(shí)踐中提取出來的，例如：

• jest: no-confusing-set-timeout
• react: jsx-no-duplicate-props
• eslint: default-case-last
• typescript: no-unnecessary-type-constraint

實(shí)現(xiàn)專門為編寫規(guī)則設(shè)計(jì)的 DSL。

Oxlint 正在研發(fā)一種專門用于編寫規(guī)則的 DSL。至于這個(gè) DSL 何時(shí)發(fā)布以及效果如何，目前尚不清楚。

從參與成本的角度來看，Eslint 完全勝出。

Oxlint 會取代 Eslint 嗎？

根據(jù)已知情況，Oxlint 規(guī)則參與成本高于 Eslint。只要這個(gè)問題沒有解決，Eslint 支持的一些規(guī)則 Oxlint 就無法支持。因此，短期內(nèi)完全取代 Eslint 是不現(xiàn)實(shí)的。

然而，就像 Vite 相對于 Webpack，前者并未實(shí)現(xiàn)后者的所有功能。但只要滿足 90% 開發(fā)者的常見需求，并提供更好的體驗(yàn)，就能吸引大多數(shù) Webpack 用戶。

Oxlint 也是如此——它建議開發(fā)者先運(yùn)行 Oxlint，然后在 lint-staged 或 CI 設(shè)置中運(yùn)行 ESLint。這樣，大多數(shù)常見問題在到達(dá) ESLint 之前就被 Oxlint 阻止了。

這種方法可以顯著提高 lint 過程的速度，并且學(xué)習(xí)曲線很低。因此，它很可能在開發(fā)者中迅速流行。

當(dāng)這種方法變得流行時(shí)，隨著 Oxlint 規(guī)則覆蓋范圍的增加，它將逐漸替代 Eslint 最常見的 90% 需求。

到那時(shí)，會出現(xiàn) Oxlint 為主，Eslint 為輔（處理少數(shù)特殊規(guī)則）的情況。

從這個(gè)角度來看，Oxlint 有很大的勝算。

盡管 Oxlint 前景光明，但它目前還有一些缺點(diǎn)，例如：

框架語法：Oxlint 原生支持 js(x) 和 ts(x)，但不支持 Svelte 或 Vue 模板語法。

vscode 插件仍不穩(wěn)定，有 bug。例如，在下面的代碼中，警告應(yīng)該在第 1 行和第 3 行，但第 2 行也被標(biāo)記了。

圖片

我相信，隨著開發(fā)團(tuán)隊(duì)的持續(xù)投入和社區(qū)生態(tài)系統(tǒng)的形成，Oxlint 及其底層 Oxc 將擁有光明的未來。