Eslint 会被 Oxlint 干掉吗？

大家好，我卡颂。

最近，一款基于Rust的linter工具Oxlint在国外前端圈引起热烈讨论，很多大佬给出了高度评价。

他相比于老大哥Eslint有什么优势？未来他会取代老大哥么？本文让我们来聊聊这个话题。

Oxc与Oxlint

oxlint是Oxc项目旗下的一款产品，Oxc作为一款Rust实现的前端工具链集合，包括：

• linter，即oxlint，对标Eslint，本文的主角
• Parser，即oxc_parser，用于解析.js(x)和.ts(x)，对标swc，基准测试[1]据称比swc快2倍

• Resolver，解析esm、cjs文件路径，对标webpack/enhanced-resolve，基准测试[2]据称比webpack快28倍
• formatter，对标Prettier，还未公布
• transpiler，对标babel，用于将高级语法转译为低级语法，还未公布
• minifier，代码压缩工具，还未公布

与Oxc抱有同样设计理念（都是基于Rust开发的工具链工具）的还有Biome与Ruff，其中：

• Biome比较命途多舛。他的前身是Rome，由Babel作者「Sebastian McKenzie」开发，和Oxc一样目标语言是JS
• Ruff的目标语言是Python

Oxlint的介绍

Oxlint之所以引发热烈讨论，主要原因是「他的性能太炸裂了」。

尤大用Oxlint跑了Vue3仓库，～590个文件跑～200条规则，仅用时50ms。

我自己（苹果M1 pro，32G）跑一个大概50个文件的小项目，也只用了18ms，官方宣称的在基准测试中比Eslint快50～100倍果然不是空穴来风。

当然，除了「性能优势」，Oxlint与老大哥Eslint还有很多区别。接下来我们从3个角度对比Oxlint与Eslint：

1. 易用性
2. 诊断可读性
3. 参与成本

易用性

Eslint诞生于2013年，他相比于竞争对手（JSHint、JSHint）最大的优势是「提供了大量可选的规则，并且一些场景下对于不符合规则的代码可以自动修复」。

但是，随着时代的进步，他的优势逐渐变为劣势 —— 开发者不再需要大量自定义规则，而是需要「开箱即用的规则集的最佳实践」。在此理念下诞生了很多新产品，比如：

• 仅针对「代码风格」做出检查和格式化的Prettier
• antfu定制版规则集eslint-plugin-antfu[3]

Oxlint吸取了上述产品的优点，默认提供了一套开箱即用的规则集。这套规则集主要关注「代码的正确性」（比如「语法错误」、「冗余代码」、「容易造成误解的语法」）而不是「代码的细节优化」（比如语法的性能、风格）。

所以，你只需要在项目执行如下命令，就能满足常规的校验：

npx oxlint@latest

从易用性上看，Oxlint比Eslint强很多。

诊断可读性

当linter诊断出问题后，会给开发者提供相关信息。Eslint给的信息通常比较简短，只告诉你「为什么报错」。比如对于如下代码：

let a;

通过信息「a is defined but never used」可以知道报错原因是「a定义了但未使用」。

但如果是更复杂的规则，简短的信息可能并不能直观表达「具体哪里报错」以及「解决办法」，很多时候我们还需要查下规则文档，看看这条规则的具体含义，再结合报错的代码分析。

相比于Eslint，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的信息包括三部分：

• 为什么报错
• 具体哪里报错
• 怎么解决

这段示例代码比较简短，可能体现不出Oxlint信息的价值，让我们看看下面这段报错信息：

一眼就能看出是哪个reduce（紫色字体）中的哪个展开操作（青色字体）引发的问题。

虽然有些同学会说：如果项目大了，lint信息这么详细看的人脑袋痛。

但我们要知道 —— 「你能提供，但我不用」和「你不能提供」完全是两个概念。

从「诊断可读性」看，Oxlint比Eslint更优秀。

参与成本

「参与成本」是指开发者自定义规则的成本。Oxlint是Rust编写的，如果开发者自定义规则也得写Rust，那成本就太高了。相比之下，Eslint的规则都是JS编写的，成本低很多。

Oxlint从2个角度出发尝试解决这个问题：

1. 你别自己写了，官方将常用的规则都写好了

截止本文发稿，官方实现了200个左右的规则，从名字就能看出，这些规则是从各个常见库的最佳实践中摘出来的，比如：

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

1. 实现一套专门编写规则的DSL

Oxlint正在研究开发一套DSL，专门用来编写规则。至于这套DSL何时问世、好不好用暂不得知。

从「参与成本」角度看，Eslint完胜。

Oxlint会取代Eslint么？

基于已知的现状 —— Oxlint规则参与成本高于Eslint，只要这个问题不解决，就一定存在某些Eslint支持，但Oxlint不支持的规则。所以，要完全取代Eslint，短期内并不现实。

但是，就像Vite之于Webpack，前者也没有实现后者的所有功能。但只要满足开发者最常见的90%需求且体验更好，就能从Webpack手中抢走大部分用户。

Oxlint显然也是这么做的 —— 他们建议开发者在lint-staged或CI设置中先运行Oxlint再运行ESLint。这样，大部分常见问题还没走到Eslint这一步就被Oxlint挡住了。

这种方式能显著提高lint流程的速度，且上手成本极低。所以很可能在开发者中快速普及开。

当这种方式普及后，随着Oxlint规则覆盖度与日俱增，会在「最常见的90%需求」中逐渐取代Eslint。

届时，会形成一种Oxlint为主，Eslint为辅（处理少量特殊规则）的局面。

从这个角度看，Oxlint的赢面很大。

后记

虽然Oxlint有着不错的前景，但当前他还存在一些不足，比如：

• 框架语法支持度不高

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

• vscode插件还不稳定，有bug

比如下面代码中警告的应该是第1、3行，但是第2行也被标记了。

相信随着开发团队的持续投入，社区生态的形成，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