从 ESLint 到 Oxlint：一次提速百倍的前端 Lint 工具链升级实战

一、前言：为什么我们需要一个新的 Linter？

在前端项目的日常开发中，ESLint 是我们保障代码质量、统一代码风格不可或缺的工具。但随着项目规模的增长，一个普遍的痛点逐渐浮现：性能。在 pre-commit 钩子中等待数十秒甚至更久的 Lint 检查，或是 IDE 中迟钝的错误提示，都在无形中消耗着我们的开发热情和效率。

这时，Oxlint 进入了我们的视野。

Oxlint 是一个使用 Rust 编写的 JavaScript/TypeScript Linter，它的核心优势只有一个字：快。得益于 Rust 的原生性能和并行处理能力，Oxlint 的执行速度通常比 ESLint 快 50 到 100 倍，能将分钟级的 Lint 过程缩短到秒级甚至毫秒级。

除了速度，Oxlint 还内置了来自 eslint、@typescript-eslint、eslint-plugin-react、eslint-plugin-jest、eslint-plugin-unicorn 和 eslint-plugin-jsx-a11y 等多个插件的核心规则，开箱即用，无需繁琐配置。

二、升级的契机：告别缓慢与陈旧

我们团队之前的配置是基于 eslint 和 eslint-config-alloy（腾讯 AlloyTeam 的一套流行配置）。这套配置虽然在当时非常优秀，但时至今日，也面临着一些挑战：

性能瓶颈：如上所述，eslint 在大型项目上的性能表现已成为开发流程中的一个明显堵点。
规则过时：许多规则在现代前端工作流中已不再是最佳实践。例如，大量与 prop-types 相关的规则，在全面拥抱 TypeScript 的今天已显得多余。
职责混淆 ：大量的代码风格规则（如空格、逗号、换行等）与代码质量规则混杂在 .eslintrc 文件中，导致配置文件臃肿且难以维护。

基于这些痛点，我们决定进行一次彻底的工具链升级，目标是：更快、更简洁、更现代。

三、升级之路：详细步骤

我们的升级过程遵循"清理、迁移、整合"的思路，确保平稳过渡。

1. 安装新工具

首先，我们需要在项目中引入 Oxlint，并为 VS Code 安装对应的插件以获得实时的 IDE 反馈。

安装 VS Code 插件：在插件市场搜索并安装 Oxlint。
安装 npm 包：
bash 复制代码
```
npm install --save-dev oxlint prettier
```
我们需要同时安装 prettier，因为它将在我们的新工作流中扮演至关重要的角色。

2. 清理旧依赖

这是非常关键的一步。为了避免新旧工具冲突，我们从 package.json 中移除了所有与 ESLint 相关的包：

bash 复制代码

npm uninstall eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin eslint-plugin-react eslint-plugin-react-hooks eslint-config-alloy eslint-config-prettier eslint-plugin-import ...

（请根据你的项目实际情况，移除所有 eslint 相关的依赖。）

3. 迁移配置文件

我们将逐一分析旧的 .eslintrc.js 文件，将其中的有效规则迁移到新的配置文件中。

四、全量规则迁移：取其精华，去其糟粕

这是本次升级的核心。我们系统地梳理了 eslint-config-alloy 默认开启的规则以及我们团队自定义的规则，遵循以下原则进行迁移。

五、职责分离：现代 Lint 工具链的哲学

我们认为，一个现代化的代码检查工具链应该各司其职，而不是将所有功能都堆砌在 Linter 中。

TypeScript (tsconfig.json) → 类型安全
- 职责：作为类型安全的最终权威。
- 实践：在 tsconfig.json 中开启 "strict": true 模式。这使得 tsc 编译器本身就能捕获大量的类型错误（如隐式 any、不安全的 null 操作等），许多 @typescript-eslint 规则因此变得不再必要。
Prettier → 代码风格
- 职责：接管所有代码格式化工作，如缩进、分号、空格、换行、逗号风格等。
- 实践：我们从 ESLint 配置中移除了所有与代码外观相关的规则，并创建了一个简洁的 .prettierrc.json 文件。这让 Linter 能专注于更有价值的事情。
Oxlint (.oxlintrc.json) → 代码质量
- 职责：负责 tsc 和 prettier 不检查的部分------代码的逻辑错误、潜在 Bug、反模式和最佳实践。
- 实践：我们将旧配置中真正关心代码质量的规则（如 no-unsafe-finally, react/jsx-key, no-var 等）迁移到 .oxlintrc.json 中。由于 Oxlint 默认开启了大量最佳实践规则，我们的最终配置文件变得异常精简。

六、最终成果：我们的配置文件

经过上述流程，我们得到了两个核心配置文件，它们简洁、清晰且易于维护。

1. Prettier 配置 (.prettierrc.json)

这份配置统一了我们团队所有的代码风格。

json 复制代码

{
  "arrowParens": "always",
  "bracketSpacing": true,
  "bracketSameLine": false,
  "jsxSingleQuote": false,
  "printWidth": 120,
  "proseWrap": "preserve",
  "semi": false,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "none",
  "useTabs": false
}

2. Oxlint 配置 (.oxlintrc.json)

这份配置只包含那些非默认开启但我们团队认为有价值的代码质量规则。

json 复制代码

{
  "plugins": ["react", "typescript"],
  "rules": {
    // 基础 JavaScript 规则
    "no-var": "error",
    "no-void": "error",
    "radix": "error",
    "eqeqeq": ["error", "always", { "null": "ignore" }],
    "no-restricted-globals": ["error", "isFinite", "isNaN"],
    "no-console": "error",
    "no-return-assign": "error",
    "curly": "error",

    // 变量和类型相关
    "new-cap": "error",

    // 函数相关
    "prefer-rest-params": "error",
    "max-params": ["error", 3],
    "max-nested-callbacks": ["error", 3],

    // 代码风格和质量
    "no-else-return": "error",
    "max-depth": ["error", 5],
    "max-lines": ["error", 500],
    "prefer-object-spread": "error",
    "prefer-object-has-own": "error",
    "prefer-promise-reject-errors": "error",

    // React 相关
    "react/self-closing-comp": "error",
    "react/jsx-no-useless-fragment": "error",
    "react/no-unescaped-entities": "error",
    "react/no-unknown-property": "error",
    "react/jsx-curly-brace-presence": ["error", "never"],
    "react/no-namespace": "error",

    // TypeScript 相关
    "typescript/no-require-imports": "error",
    "typescript/no-non-null-asserted-nullish-coalescing": "error",
    "typescript/adjacent-overload-signatures": "error",
    "typescript/consistent-type-definitions": ["error", "interface"],
    "typescript/no-empty-interface": "error",
    "typescript/no-inferrable-types": "error",
    "typescript/prefer-for-of": "error",
    "typescript/prefer-function-type": "error",
    "typescript/prefer-namespace-keyword": "error"
  },
  "globals": {
    "REACT_APP_ENV": "readonly",
    "definePageConfig": "readonly",
    "defineAppConfig": "readonly"
  },
  "ignorePatterns": ["tools/**/*.js", "scripts/*"]
}

七、提升体验：配置 VS Code 保存时自动修复

为了最大化开发效率，我们配置了 VS Code 在保存文件时自动运行 Oxlint 和 Prettier 进行修复。

在项目的 .vscode/settings.json 文件中添加以下配置：

json 复制代码

{
  // 优先使用 Prettier 作为默认格式化工具
  "editor.defaultFormatter": "esbenp.prettier-vscode"
  // 保存时自动格式化
  "editor.formatOnSave": true,
  // 保存时自动运行 Oxlint 修复
  "editor.codeActionsOnSave": {
    "source.fixAll.oxc": "explicit"
  }
}

现在，每次按下 Ctrl + S，代码不仅会被格式化，还会被 Oxlint 自动修复大部分可修复的错误，体验如丝般顺滑。

八、总结

这次从 ESLint 到 Oxlint 的迁移，需要综合对比原先ESlint的规则并找寻新的适合的规则方案进行映射整合,工作量着实也不算小。但是给我们团队带来了远超预期的收益：

极致的速度：Lint 时间从分钟级降至秒级，pre-commit 检查不再是负担。
简洁的配置：告别了数百行的 .eslintrc 文件，新的配置一目了然。
清晰的职责：TypeScript、Oxlint、Prettier 各司其职，工具链更加稳固和现代化。

我们此次的整合是基于基础框架模板的全量升级。如果你的项目已经迭代多年并且代码量相对庞大的话。我们更建议你采用官方的渐进式升级方案。

如果你或你的团队也正受困于 ESLint 的性能问题，或渴望拥抱一套更现代、更高效的前端工具链，那么，是时候给 Oxlint 一个机会了。