最近，一个基于 Rust 的代码检查工具 Oxlint 在国外前端社区引起了热议，许多专家对其给予了高度评价。那么，相比于它的大哥 Eslint，Oxlint 有哪些优势？它会在未来取代 Eslint 吗？本文将讨论这个话题。

Oxc 和 Oxlint

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

• Linter：即 Oxlint，可与 Eslint 相媲美，是本文的主角

• Parser：即 oxc_parser，用于解析 .js(x) 和 .ts(x)，可与 swc 媲美。基准测试声称其速度是 swc 的两倍

• Resolver：解析 ESM 和 CJS 文件的路径，基准测试显示其速度比 webpack/enhanced-resolve 快 28 倍

• Formatter：基准测试对比 Prettier，尚未公布

• Transpiler：对比 Babel 用于将高级语法转为低级语法，尚未公布

• Minifier：代码压缩工具，尚未公布

除了与 Oxc 具有相同设计理念的工具（所有工具链工具均基于 Rust 开发）之外，还有 Biome 和 Ruff：

• Biome：其前身是由 Babel 作者 Sebastian McKenzie 开发的 Rome。目标语言是 JS

• Ruff：目标语言是 Python

Oxlint 介绍

Oxlint 引发热议的主要原因是其爆炸性的性能。

我使用 Apple M1 Pro 32G 运行一个包含约 50 个文件的小项目，仅用了 18ms，官方声称其基准测试中比 Eslint 快 50-100 倍的说法并非虚言。

当然，除了性能优势外，Oxlint 与 Eslint 还有许多不同之处。接下来，我们将从三个方面比较 Oxlint 和 Eslint：

易用性

Eslint 诞生于 2013 年。相比于竞争对手（如 JSHint），其最大的优势在于提供大量可选规则，并在某些场景下可以自动修复不符合规则的代码。

然而，随着时间推移，这一优势逐渐变成劣势——开发者不再需要大量自定义规则，而是需要基于最佳实践的开箱即用规则集。许多新产品正是基于这一概念而诞生的，如：

• Prettier：仅检查和格式化代码风格

• eslint-plugin-antfu：Antfu 自定义规则集的版本

Oxlint 借鉴了上述产品的优势，提供了一套开箱即用的默认规则。这套规则主要关注代码的正确性（如语法错误、冗余代码和容易引起误解的语法），而不是优化代码细节（如语法性能或风格）。

因此，只需要在项目中执行以下命令即可满足常规验证：

npx oxlint@latest

在易用性方面，Oxlint 远胜于 Eslint。

可读性诊断

当代码检查工具检测到问题时，它会向开发者提供相关信息。Eslint 提供的信息通常很简短，只告诉你错误的原因。例如，对于以下代码：

let a;

通过信息 "a is defined but never used"，我们可以知道错误的原因是变量 a 被定义但未使用。

然而，如果是更复杂的规则，简短的信息可能无法直观地表达错误发生的位置和解决方法。许多时候，我们仍需查看规则文档，了解该规则的具体含义，然后结合错误代码进行分析。

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

• 错误原因

• 错误具体发生的位置

• 解决方法

通过查看代码中的哪个 reduce 操作（紫色字体）和哪个扩展操作（青色字体），我们可以识别问题。

虽然有些人可能会说，如果项目很大，阅读如此详细的 lint 信息是一种头疼的事。

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

在诊断可读性方面，Oxlint 优于 Eslint。

参与成本

参与成本指的是开发者自定义规则的成本。Oxlint 是用 Rust 编写的，如果开发者需要用 Rust 来编写自定义规则，成本会很高。相比之下，Eslint 的规则是用 JS 编写的，成本要低得多。

Oxlint 尝试从两个方面解决这个问题：

不需要自己编写，官方已经编写了常用规则。

截至本文撰写时，官方已经实现了大约 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 也是如此——它建议开发者先运行 Oxlint，然后在 lint-staged 或 CI 设置中运行 ESLint。这样，大多数常见问题在到达 ESLint 之前就被 Oxlint 阻止了。

这种方法可以显著提高 lint 过程的速度，并且学习曲线很低。因此，它很可能在开发者中迅速流行。

当这种方法变得流行时，随着 Oxlint 规则覆盖范围的增加，它将逐渐替代 Eslint 最常见的 90% 需求。

到那时，会出现 Oxlint 为主，Eslint 为辅（处理少数特殊规则）的情况。

从这个角度来看，Oxlint 有很大的胜算。

尽管 Oxlint 前景光明，但它目前还有一些缺点，例如：

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

vscode 插件仍不稳定，有 bug。例如，在下面的代码中，警告应该在第 1 行和第 3 行，但第 2 行也被标记了。

我相信，随着开发团队的持续投入和社区生态系统的形成，Oxlint 及其底层 Oxc 将拥有光明的未来。

最后：

vue2与vue3技巧合集

VueUse源码解读