一、Oxlint 简介

官网：https://oxc-project.github.io/

Oxc (The Oxidation Compiler) 是一个用 Rust 编写的 JavaScript 和 TypeScript 高性能工具集合。Oxc 正在构建一个解析器、linter、格式化程序、转译器、压缩器、解析器。

Oxlint 是一种静态代码分析工具，旨在通过检测错误和执行代码样式规则来提高代码质量。与用 JavaScript 编写的 ESLint 不同，Oxlint 是用 Rust 开发的，Rust 以其性能和安全性而闻名，这赋予了 Oxlint 显著的速度优势。

二、特性

1. 性能

处理代码的速度比 ESLint 快 50-100 倍，并且会随着 CPU 核心的数量而扩展。
下图为 Oxlint 与 ESLint 耗费时间对比：

尤雨溪在试用之后都在感叹 Oxlint 的速度之快。

2. 开箱即用零配置

Oxlint 提供了一套默认的规则集，这套规则集主要关注代码的正确性（比如语法错误、冗余代码、容易造成误解的语法）而不是代码的细节优化（比如语法的性能、风格）。

OxLint 做到了开箱即用的零配置，甚至连 Node.js 都不是必需的，可直接通过命令行操作。

而我们熟知的 ESLint 则是提供了大量可选的规则，使用者可利用其插件化和可层叠配置的特性来进行项目的定制化配置。基于此特性诞生了很多产品和工具包，如专注代码风格的 prettier、专注 TypeScript  规则的 @typescript-eslint/eslint-plugin 等。如果将 ESLint 应用到工程中，则需要安装多个包以及进行相关的配置。

3. 诊断可读性

ESLint 诊断出问题后，给出的信息往往比较简短，只告知为什么报错，却不能直观的表达具体哪里报错以及应该如何解决，很多时候需要使用者自行查阅规则文档再结合报错代码进行分析改进。

而 Oxlint 诊断出问题的信息则更加详细和智能，它会告知为什么报错、哪里报错甚至会给出如何解决的建议。

4. 兼容性

支持 .eslintignore 、.eslintrc.json 和 ESLint comment disabled。
适用于大多数为 ESLint 设计的配置和插件。

三、安装与使用

1. 安装

常规 npm 安装：

1
2
3
npm install -D oxlint

yarn add -D oxlint

2. 参数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
用法: oxlint [-A=NAME | -D=NAME]... [--fix] [-f] [-c=PATH] [--tsconfig=PATH] [PATH]...

关闭和开启规则：
  举例： `-D correctness -A no-debugger` 或 `-A all -D no-debugger`.
  默认开启的规则集是 correctness.
  "--rules" 展示所有支持的规则.
  "--help --help" 展示所有支持的规则集合.
  -A, --allow=NAME          关闭哪些规则或规则集合
  -D, --deny=NAME           开启哪些规则或规则集合

开启插件：
        --import-plugin       启用实验性的导入插件并检测ESM问题
        --jest-plugin         启用 Jest 插件并检测测试问题
        --jsx-a11y-plugin     启用 JSX-a11y 插件并检测可访问性问题
        --nextjs-plugin       启用 Next.js 插件并检测 Next.js 问题
        --react-perf-plugin   启用React性能插件并检测渲染性能问题

问题修复：
        --fix                 尽可能多地解决问题。输出中只报告未解决的问题

忽略文件：
        --ignore-path=PATH    指定要用作.elinignore的文件
        --ignore-pattern=PAT  指定要忽略的文件模式（除了.eslitingnore 中指定之外的）
        --no-ignore           禁止从.elinignore文件中排除文件, --ignore-path --ignore-pattern

告警处理：
        --quiet               禁用警告报告，只报告错误
        --deny-warnings       确保警告产生非零退出代码
        --max-warnings=INT    指定一个警告阈值，如果项目中存在太多违反警告级别规则的情况，该阈值可用于强制退出并显示错误状态

输出：
        -f, --format          使用特定的输出格式（默认为json）

多线程：
        --threads=INT         要使用的线程数。设置为1以仅使用1个CPU核心

其他参数:
        --rules               列出当前注册的所有规则
    -c, --config=PATH         ESLint 配置文件 (experimental)
        --tsconfig=PATH       TypeScript“tsconfig.json”路径，用于读取导入插件的路径别名和项目引用
    -h, --help                帮助信息
    -V, --version             版本信息

3. 相关工具

3.1 eslint-plugin-oxlint

借助 eslint-plugin-oxlint，可以关闭 ESLint 中 Oxlint 已经支持的规则，这样可以在 ESLint 项目中结合 Oxlint 来进行代码 Lint，提高速度。

3.2 lint-staged

1
2
3
4
5
{
  "lint-staged": {
    "**/*.{js,mjs,cjs,jsx,ts,mts,cts,tsx,vue,astro,svelte}": "oxlint"
  }
}

3.3 VSCode 插件

Visual Studio Marketplace

3.4 Vite 插件

https://github.com/52-entertainment/vite-plugin-oxlint

3.5 pre-commit

1
2
3
4
5
6
repos:
  - repo: https://github.com/oxc-project/mirrors-oxlint
    rev: v0.0.0 # change to the latest version
    hooks:
      - id: oxlint
        verbose: true

四、与 ESLint 的对比

为了方便演示两个工具在实际应用中的表现，–下表– 中关于在项目中应用的介绍以某业务工程为例。

ESLint Oxlint Note
运行速度 10.6s
ESLint 的控制台输出没有时间，此时间为秒表计时，不够严谨。		 34ms --
包数量 4 个
除 ESLint 工具本身以外，至少还需要 React、TypeScript、Standard 三个 ESLint Plugin		 1个 事实上，除 ESLint Plugin 外，工程中还需要使用 ESLint config 包来使用 默认/推荐 的规则配置
配置项 较复杂
需配置插件、规则集及对应告警等级（error、warning）		 较简单
可以零配置使用，只有规则可配置		 --
报错信息 简单
 详细
Oxlint 的报错信息会明确告知错误在哪里，为什么报错和如何解决，更加详细和智能。
规则数量 多
目前 ESLint 的生态非常繁荣，相关的各技术栈的插件工具以及规则多到难以统计。		 少
目前 Oxlint 仅支持 318 个规则。		 Oxlint 不支持extends中的rules规则，这导致只能使用Oxlint 的现有规则
可定制化程度 高
基于 ESLint 插件化和可层叠配置的特性，社区有非常多的插件。插件提供了各种定制化的规则，使用者可以按需引用插件定制规则。		 低
Oxlint  仅可以从目前已支持 318 个规则当中进行定制。		 ESLint 有成熟的插件化系统，而 Oxlint 暂时不支持插件系统。
参与开发成本 低
ESLint 及其插件都是基于 JavaScript 开发，开发者参与规则开发成本较低。		 高
Oxlint 是基于 Rust 编写，自定义规则需使用 Rust，成本较高。		 Oxlint 正在研究开发一套，专门用来编写规则，但何时问世和是否好用暂不得知。

五、思考

1. Oxlint 是否会取代 ESLint

At the current stage, oxlint is not intended to fully replace ESLint; it serves as an enhancement when ESLint’s slowness becomes a bottleneck in your workflow.

We recommend running oxlint before ESLint in your lint-staged or CI setup for a quicker feedback loop, considering it only takes a few seconds to run on large codebases.

以上为 Oxlint 官网的内容，现阶段 Oxlint 的目标不是完全替代 ESLint，而且使用 Oxlint 作为性能增强。

官方建议开发者在 lint-staged 或 CI 设置中先运行 Oxlint 再运行 ESLint。这样，大部分常见问题还没走到 ESLint 这一步就被 Oxlint 挡住了，可以极大缩短时间。

2. Oxlint 的不足之处

Oxlint 刚刚发布面市，其生态支持和功能的完备肯定不及已经成熟的 ESLint。必然需要一段时间才能达到 ESLint 插件、规则的同等水平。

Oxlint 的规则参与成本远高于 ESLint，这个问题不解决，就一定存在某些 ESLint 支持，而 Oxlint 不支持的规则，所以要取代 ESLint，短期内不现实。

3. Oxlint 的前景如何

Oxlint 能显著提高代码 lint 流程的速度且上手成本很低，所以有很大可能迅速普及开。普及开后，随着 Oxlint 规则的覆盖度与日俱增，能够覆盖大部分需求，届时可能会形成一种 Oxlint 为主，ESLint 为辅的局面， 而且 Oxlint 正在布局用于规则编写的 DSL，如果 DSL 的效果比较好的话，从这个角度看，Oxlint 的赢面很大。