大家好，我卡頌。

最近，一款基于Rust的linter工具Oxlint在國外前端圈引起熱烈討論，很多大佬給出了高度評價。

他相比于老大哥Eslint有什么優(yōu)勢？未來他會取代老大哥么？本文讓我們來聊聊這個話題。

Oxc與Oxlint

oxlint是Oxc項目旗下的一款產(chǎn)品，Oxc作為一款Rust實現(xiàn)的前端工具鏈集合，包括：

• linter，即oxlint，對標Eslint，本文的主角。
• Parser，即oxc_parser，用于解析.js(x)和.ts(x)，對標swc，基準測試[1]據(jù)稱比swc快2倍。

• Resolver，解析esm、cjs文件路徑，對標webpack/enhanced-resolve，基準測試[2]據(jù)稱比webpack快28倍。
• formatter，對標Prettier，還未公布。
• transpiler，對標babel，用于將高級語法轉(zhuǎn)譯為低級語法，還未公布。
• minifier，代碼壓縮工具，還未公布。

與Oxc抱有同樣設(shè)計理念（都是基于Rust開發(fā)的工具鏈工具）的還有Biome與Ruff，其中：

• Biome比較命途多舛。他的前身是Rome，由Babel作者「Sebastian McKenzie」開發(fā)，和Oxc一樣目標語言是JS。
• Ruff的目標語言是Python。

Oxlint的介紹

Oxlint之所以引發(fā)熱烈討論，主要原因是「他的性能太炸裂了」。

尤大用Oxlint跑了Vue3倉庫，～590個文件跑～200條規(guī)則，僅用時50ms。

我自己（蘋果M1 pro，32G）跑一個大概50個文件的小項目，也只用了18ms，官方宣稱的在基準測試中比Eslint快50～100倍果然不是空穴來風(fēng)。

當然，除了「性能優(yōu)勢」，Oxlint與老大哥Eslint還有很多區(qū)別。接下來我們從3個角度對比Oxlint與Eslint：

• 易用性
• 診斷可讀性
• 參與成本

易用性

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

但是，隨著時代的進步，他的優(yōu)勢逐漸變?yōu)榱觿?—— 開發(fā)者不再需要大量自定義規(guī)則，而是需要「開箱即用的規(guī)則集的最佳實踐」。在此理念下誕生了很多新產(chǎn)品，比如：

• 僅針對「代碼風(fēng)格」做出檢查和格式化的Prettier。
• antfu定制版規(guī)則集eslint-plugin-antfu[3]。

Oxlint吸取了上述產(chǎn)品的優(yōu)點，默認提供了一套開箱即用的規(guī)則集。這套規(guī)則集主要關(guān)注「代碼的正確性」（比如「語法錯誤」、「冗余代碼」、「容易造成誤解的語法」）而不是「代碼的細節(jié)優(yōu)化」（比如語法的性能、風(fēng)格）。

所以，你只需要在項目執(zhí)行如下命令，就能滿足常規(guī)的校驗：

npx oxlint@latest

從易用性上看，Oxlint比Eslint強很多。

診斷可讀性

當linter診斷出問題后，會給開發(fā)者提供相關(guān)信息。Eslint給的信息通常比較簡短，只告訴你「為什么報錯」。比如對于如下代碼：

let a;

通過信息「a is defined but never used」可以知道報錯原因是「a定義了但未使用」。

但如果是更復(fù)雜的規(guī)則，簡短的信息可能并不能直觀表達「具體哪里報錯」以及「解決辦法」，很多時候我們還需要查下規(guī)則文檔，看看這條規(guī)則的具體含義，再結(jié)合報錯的代碼分析。

相比于Eslint，Oxlint的信息更直觀與準確。舉個例子，下面的代碼執(zhí)行后會得到「數(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);

這里每次執(zhí)行reduce回調(diào)都會將數(shù)組展開，當數(shù)組比較長時會造成性能問題。

對此，Oxlint的信息包括三部分：

• 為什么報錯
• 具體哪里報錯
• 怎么解決

這段示例代碼比較簡短，可能體現(xiàn)不出Oxlint信息的價值，讓我們看看下面這段報錯信息：

一眼就能看出是哪個reduce（紫色字體）中的哪個展開操作（青色字體）引發(fā)的問題。

雖然有些同學(xué)會說：如果項目大了，lint信息這么詳細看的人腦袋痛。

但我們要知道 —— 「你能提供，但我不用」和「你不能提供」完全是兩個概念。

從「診斷可讀性」看，Oxlint比Eslint更優(yōu)秀。

參與成本

「參與成本」是指開發(fā)者自定義規(guī)則的成本。Oxlint是Rust編寫的，如果開發(fā)者自定義規(guī)則也得寫Rust，那成本就太高了。相比之下，Eslint的規(guī)則都是JS編寫的，成本低很多。

Oxlint從2個角度出發(fā)嘗試解決這個問題：

你別自己寫了，官方將常用的規(guī)則都寫好了。

截止本文發(fā)稿，官方實現(xiàn)了200個左右的規(guī)則，從名字就能看出，這些規(guī)則是從各個常見庫的最佳實踐中摘出來的，比如：

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

實現(xiàn)一套專門編寫規(guī)則的DSL。

Oxlint正在研究開發(fā)一套DSL，專門用來編寫規(guī)則。至于這套DSL何時問世、好不好用暫不得知。

從「參與成本」角度看，Eslint完勝。

Oxlint會取代Eslint么？

基于已知的現(xiàn)狀 —— Oxlint規(guī)則參與成本高于Eslint，只要這個問題不解決，就一定存在某些Eslint支持，但Oxlint不支持的規(guī)則。所以，要完全取代Eslint，短期內(nèi)并不現(xiàn)實。

但是，就像Vite之于Webpack，前者也沒有實現(xiàn)后者的所有功能。但只要滿足開發(fā)者最常見的90%需求且體驗更好，就能從Webpack手中搶走大部分用戶。

Oxlint顯然也是這么做的 —— 他們建議開發(fā)者在lint-staged或CI設(shè)置中先運行Oxlint再運行ESLint。這樣，大部分常見問題還沒走到Eslint這一步就被Oxlint擋住了。

這種方式能顯著提高lint流程的速度，且上手成本極低。所以很可能在開發(fā)者中快速普及開。

當這種方式普及后，隨著Oxlint規(guī)則覆蓋度與日俱增，會在「最常見的90%需求」中逐漸取代Eslint。

屆時，會形成一種Oxlint為主，Eslint為輔（處理少量特殊規(guī)則）的局面。

從這個角度看，Oxlint的贏面很大。

后記

雖然Oxlint有著不錯的前景，但當前他還存在一些不足，比如：

• 框架語法支持度不高

Oxlint原生支持js(x)、ts(x)，但不支持Svelte、Vue模版語法。

• vscode插件還不穩(wěn)定，有bug

比如下面代碼中警告的應(yīng)該是第1、3行，但是第2行也被標記了。

相信隨著開發(fā)團隊的持續(xù)投入，社區(qū)生態(tài)的形成，Oxlint及其背后的Oxc會有不錯的未來。

參考資料

[1]基準測試:https://github.com/oxc-project/bench-javascript-parser-written-in-rust。

[2]基準測試:https://github.com/oxc-project/bench-nodejs-resolver。

[3]eslint-plugin-antfu:https://github.com/antfu/eslint-plugin-antfu?tab=readme-ov-file。