大家好，我卡颂。
最近，一款基于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：
- 易用性
- 诊断可读性
- 参与成本
易用性
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个角度出发尝试解决这个问题：
你别自己写了，官方将常用的规则都写好了。
截止本文发稿，官方实现了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显然也是这么做的 —— 他们建议开发者在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。
