码云前端开发 2023-12-15

Oxlint 会替代 Eslint 吗？

文章目录隐藏

Oxc 与 Oxlint
Oxlint 的介绍

易用性
诊断可读性
参与成本

Oxlint 会取代 Eslint 么？
后记

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

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

Oxc 与 Oxlint

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

linter，即oxlint，对标Eslint，本文的主角
Parser，即oxc_parser，用于解析.js(x)和.ts(x)，对标swc，基准测试据称比swc快 2 倍
Resolver，解析esm、cjs文件路径，对标webpack/enhanced-resolve，基准测试据称比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

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的信息包括三部分：