我们很高兴地宣布 oxlint 现在正式发布了！ 这一里程碑标志着我们团队能够及时处理和甄别问题。

Oxlint 是一个 JavaScript linter，旨在捕获错误或无用的代码，默认情况下无需任何配置。

如何使用 ​

在这个阶段，oxlint 并非旨在完全取代 ESLint；当 ESLint 的速度成为工作流中的瓶颈时，它可作为一种增强手段。

为了更快的反馈循环，我们建议在 lint-staged 或 CI 设置中先运行 oxlint 再运行 ESLint，因为它在大型代码库上运行只需几秒钟。

要在您的 JavaScript / TypeScript 代码库中测试 oxlint，只需在仓库的根目录执行以下命令：

$ npx oxlint@latest

$ pnpm dlx oxlint@latest

$ yarn dlx oxlint@latest

$ bunx oxlint@latest

$ deno run npm:oxlint@latest

或者，参考 安装指南 获取详细说明。

设计 ​

比 ESLint 快 50-100 倍 ​

在实际场景中，Shopify 报告称他们原本需要 75 分钟的 CI ESLint 运行现在只需 10 秒。

来自 Shopify DX 兼 Preact 创作者 Jason Miller：

oxlint 对我们在 Shopify 来说是一个巨大的胜利。我们之前的 lint 设置运行需要 75 分钟，所以我们在 CI 中将其分散到 40+ 个 worker 上。

相比之下，oxlint 在单个 worker 上 lint 相同的代码库只需大约 10 秒，且输出更易于理解。

我们在迁移时甚至发现了一些被旧设置隐藏或跳过的问题！

大部分性能提升源于 Oxlint 专为性能而设计，利用 Rust 和并行处理作为关键因素。

专注于正确性的 Lint ​

Oxlint 默认旨在识别错误、冗余或令人困惑的代码——优先保证正确性，而不是不必要的吹毛求疵的规则（分类为 perf、suspicious、pedantic 或 style），这些规则默认是禁用的。

易于使用 ​

设置新的 JavaScript / TypeScript 代码库正变得日益复杂。 很有可能遇到工具之间的兼容性问题，从而导致浪费数小时的时间。

这就是为什么我们将 oxlint 设计为开箱即用的零配置；甚至不需要 Node.js。 大多数调整可以通过命令行完成，读取 ESLint 配置文件的功能目前正在进行中。

增强的诊断信息 ​

理解 linter 消息可能具有挑战性。 Oxlint 旨在通过定位根本原因并提供有帮助的消息来简化这一点——消除了阅读冗长规则文档的需要，节省宝贵时间。

在 vscode 仓库 中运行 oxlint -D perf：

整合的规则 ​

Oxlint 尚未提供插件系统，但我们正在积极整合来自流行插件的规则，如 TypeScript、React、Jest、Unicorn、JSX-a11y 和 Import。

我们认识到插件在 JavaScript 生态系统中的重要性，并且也在调查基于 DSL 的插件系统。

不过，您可能会欣赏独立的 linter——无需管理插件依赖列表， 浏览 兼容性问题， 或 因版本限制而使用分支插件。

祝您 lint 愉快，节日快乐！

要开始使用，请遵循 安装指南， 了解更多关于 oxc 项目， 或在 Hacker News 上讨论。

我们很高兴宣布 oxlint --import-plugin 的 alpha 版本发布，它是 eslint-plugin-import 的移植版本。

此移植版本旨在解决与 eslint-plugin-import 相关的所有已知问题：

• 性能 - 启用某些规则时执行时间超过一分钟
• 依赖大小 - 188 个依赖项，总计 30M
• 向后兼容性 - 需要 支持 Node.js v4.0.0
• 依赖兼容性 - 需要将其替换为 eslint-plugin-import-x
• 升级到 ESLint v9

发布内容是什么？ ​

如果您的项目使用 ESM（ECMAScript 模块），预计此 alpha 版本可以正常工作。

如果需要通过 tsconfig.compilerOptions.paths 配置路径别名（例如 @/foo），可以使用 --tsconfig 选项：

npx oxlint@latest --tsconfig ./tsconfig.json --import-plugin

通过 npx oxlint@latest --import-plugin 默认启用的规则有：

• default
• named
• namespace

可以通过 npx oxlint@latest --import-plugin -D rule-name 选择性启用的规则有：

• no-named-as-default
• no-named-as-default-member
• no-self-import
• no-duplicates
• no-amd
• no-default-export
• no-cycle

这些规则也有所改进；例如，no-cycle 规则的诊断信息得到了改进：

 ⚠ eslint-plugin-import(no-cycle): Dependency cycle detected
   ╭─[apps/web/playwright/lib/fixtures.ts:13:42]
12 │ import { createPaymentsFixture } from "../fixtures/payments";
13 │ import { createBookingPageFixture } from "../fixtures/regularBookings";
   ·                                          ─────────────────────────────
14 │ import { createRoutingFormsFixture } from "../fixtures/routingForms";
   ╰────
 help: These paths form a cycle:
       -> ../fixtures/regularBookings - apps/web/playwright/fixtures/regularBookings.ts
       -> ./users - apps/web/playwright/fixtures/users.ts
       -> ../lib/testUtils - apps/web/playwright/lib/testUtils.ts
       -> ./fixtures - apps/web/playwright/lib/fixtures.ts

这并不是一个很长的功能列表，但由于当前生态系统状态的复杂性，实现这些规则并确保它们正常工作需要大量的努力。

在过去的六个月里，我们利用业余时间工作，并成功完成了 --import-plugin 工作所需的所有先决条件：

• 一个用于模块解析的 resolver
• 一个小型 "runtime" 以最大化并行处理依赖文件
• 一个用于存储导入/导出信息的 ModuleRecord 数据结构，及其相应的 builder

我如何提供帮助？ ​

如果您是项目维护者（即配置工程师），并且没有时间和精力保持 ESLint 及其所有插件更新，您可以跟随 @brooooooklyn 的脚步，在他所有的项目中用 oxlint 替换 ESLint。

如果您是开源爱好者并愿意提供帮助，欢迎在 discord 上与我们交谈，查看 linter 产品计划和进度问题，或通过 提议新的规则 来帮助（那些被推迟的规则）。

如果您是工程经理，或者愿意将项目迁移到 oxlint（拥有 330 条规则且还在增长）以降低基础设施成本，您可以考虑 赞助，以便我们可以优先处理您的项目。

请记住 oxlint 目前是由社区驱动的，我相信只要有足够的资源，我们就可以在未来几个月内使 --import-plugin 普遍可用。

要开始使用 oxlint，请遵循 安装指南 或了解更多关于 oxc 项目 的信息。

我们很高兴宣布 Oxc transform（又名 transpile）的 alpha 版本发布。

此版本包含三个主要功能：

1. 将 TypeScript 转换为 ESNext。
2. 将 React JSX 转换为 ESNext，内置 React Refresh。
3. TypeScript Isolated Declarations DTS 生成 无需使用 TypeScript 编译器。

在这个 alpha 阶段，我们建议尝试这些功能以加快构建速度。

我们的基准测试 显示：

• Transform：Oxc 比 SWC 快 3 倍 - 5 倍，内存使用减少 20%，包体积更小（2 MB 对比 SWC 的 37 MB）。
• Transform：Oxc 比 Babel 快 20 倍 - 50 倍，内存使用减少 70%，体积小 19 MB，只需安装 2 个 npm 包，而 Babel 需要 170 个。
• React 开发 + React Refresh：Oxc 比 SWC 快 5 倍，比 Babel 快 50 倍。
• TS isolated declarations .d.ts 生成：Oxc 在典型文件上比 TSC 快 40 倍，在较大文件上快 20 倍。

使用示例 ​

oxc-transform npm 包 ​

Vue.js 目前在其构建管道中 实验 使用 oxc-transform npm 包进行 isolated declarations：

import { isolatedDeclaration } from "oxc-transform";
const dts = isolatedDeclaration(filename, ts);

@lukeed 和 @maraisr 正在他们的包 empathic 和 dldr 中使用 oxc-transform 来 单步完成 转换和生成 .d.ts。

以下示例演示了在单个转换步骤中发出 .js 和 .d.ts：

import { transform } from "oxc-transform";
const transformed = transform(filePath, sourceCode, {
  typescript: {
    onlyRemoveTypeImports: true,
    declaration: { stripInternal: true },
  },
});
await fs.writeFile("out.js", transformed.code);
await fs.writeFile("out.d.ts", transformed.declaration);

unplugin-isolated-decl ​

vue-macros 使用 unplugin-isolated-decl 作为其 esbuild 插件的集成工具。

@sxzz 报告 他们的 .d.ts 生成时间从 76 秒减少到 16 秒。

Airtable 的 Bazel 构建 ​

来自 Airtable 的 @michaelm 正在其 Bazel 构建 的 CI 管道中集成 Oxc 的 isolated declarations .d.ts 生成功能。

Rust oxc_transformer crate ​

Rolldown 打包器 直接 使用 oxc_transformer Rust crate。

基准测试结果 ​

基准测试设置位于 oxc-project/bench-transformer 并且基准测试结果显示在其 GitHub Actions 中。

（欢迎纠正任何配置错误。）

在 ubuntu-latest 上，测量了不同代码行数的示例：

转换 ​

Isolated Declarations ​

包大小 ​

Oxc 仅下载 2 个 npm 包，总共 2 MB。

内存使用 ​

Oxc 使用更少的内存。

转换 parser.ts（10777 行）的内存使用 - 使用 /usr/bin/time -alh node 测量：

下一个版本 ​

我们的下一个版本将包括目标降级到 ES6 和 @babel/plugin-transform-modules-commonjs。

致谢 ​

感谢 @Dunqing 和 @overlookmotel 为本版本发布所做的所有辛勤工作。

感谢 snyder.tech、schoolhouse.world、@lukeed 和 @maraisr 的慷慨 赞助。

Oxlint v0.10.0 来了！此版本包含几个令人兴奋的功能，包括对配置文件的许多改进。

新功能 ​

新规则 ​

此版本包含以下新规则：

• promise/no-callback-in-promise
• react/iframe-missing-sandbox
• node/no-new-require

并为以下规则添加了自动修复/建议：

• eslint/no-plusplus

按类别启用/禁用规则 ​

现在，您可以在配置文件中使用 categories 字段来启用或禁用整个类别的规则。

现在，无需运行此命令：

oxlint -D correctness -W suspicious -c oxlint.json

您可以向 oxlint.json 添加一个 categories 字段：

{
  "categories": {
    "correctness": "deny", 
    "suspicious": "warn", 
  }, 
  "rules": {
    "no-const-assign": "error",
    "import/no-cycle": "error",
  },
}

并去掉 -D 和 -W 标志。

配置文件中现在支持 plugins ​

配置文件现在支持来自 ESLint v8 配置的 plugins 数组。 这允许您无需 CLI 参数即可启用插件，从而可以在 VSCode 中使用插件。

{
  "plugins": ["import"], 
  "categories": {
    "correctness": "deny",
    "suspicious": "warn",
  },
  "rules": {
    "react/jsx-uses-react": "off",
    "react/react-in-jsx-scope": "off",
  },
}

这与 categories 配合良好，因为启用/禁用的类别也会影响插件。

{
  "plugins": ["import"],
  // `categories` 影响所有启用的插件
  "categories": {
    "correctness": "allow",
    "suspicious": "warn",
  },
  "rules": {
    "no-const-assign": "error",
    "import/no-cycle": "error",
  },
}

破坏性变更和迁移指南 ​

CLI 与配置文件规则优先级 ​

以前，配置文件会覆盖 CLI 参数中设置的规则。例如，运行此命令：

oxlint -A correctness -c oxlintrc.json

使用此配置文件

{
  "rules": {
    "no-const-assign": "error",
  },
}

将导致仅有一条规则 no-const-assign 在错误级别开启，而所有其他规则被禁用（即设置为 "allow"）。

现在，CLI 参数将覆盖配置文件。相同的命令配合相同的配置文件将导致 所有规则被禁用。要获得与之前相同的行为，请在配置文件中启用和禁用类别，而不是使用 CLI 参数。

oxlint -c oxlint.json

{
  "categories": {
    "correctness": "allow", 
  }, 
  "rules": {
    "no-const-assign": "error",
  },
}

我们很高兴宣布 oxc-minify 的 Alpha 版本发布。

虽然缺少一些高级压缩技术， 但当前版本在性能和压缩大小方面已经优于 esbuild， 正如 minification-benchmarks 所示。

在 typescript.js 上对比广泛使用的压缩器：

oxc-minify 使用示例 ​

import { minify } from "oxc-minify";

const filename = "test.js";
const code = "const x = 'a' + 'b'; console.log(x);";
const options = {
  compress: {
    target: "esnext",
  },
  mangle: {
    toplevel: false,
  },
  codegen: {
    removeWhitespace: true,
  },
  sourcemap: true,
};
const result = minify(filename, code, options);

console.log(result.code);
console.log(result.map);

下一步发布计划 ​

oxc-minify 正在被集成到 Rolldown 中作为其内置压缩器， 而 Rolldown 注定要 成为 Vite 的未来。

因此，对我们来说至关重要的一点是：

• 继续实现高级压缩技术，例如常量内联和死代码消除。
• 加强和扩展我们的测试基础设施，以确保其准备好投入生产使用。

致谢 ​

感谢 @sapphi-red 改进了压缩器， 尤其是 esbuild 所缺乏的高级符号压缩算法。

我们很高兴地宣布，经过社区一年多的开发，Oxlint 现已进入 Beta 发布阶段！

这个里程碑代表着在功能完整性、性能和稳定性方面迈出了重要的一步。

如何使用 ​

在这个阶段，Oxlint 可用于在中小型项目中完全替代 ESLint。

对于大型项目，我们的建议是通过 eslint-plugin-oxlint 关闭 ESLint 规则， 并在本地或 CI 设置中在 ESLint 之前运行 Oxlint，以获得更快的反馈循环。

要在代码库中测试 Oxlint，您可以在代码库根目录使用您选择的包管理器：

$ npx oxlint@latest

$ pnpm dlx oxlint@latest

$ yarn dlx oxlint@latest

$ bunx oxlint@latest

$ deno run npm:oxlint@latest

有关如何使用 Oxlint 并将其与您的项目或编辑器集成的更详细说明，请查看 安装指南。

自正式发布以来的新功能亮点 ​

• 显著的性能改进，与上一个版本相比速度最快提升两倍
• 内置超过 500 条规则，无需额外安装
• 来自 typescript、unicorn、react、react-perf、nextjs、import、jsdoc、jsx-a11y、node、promise、jest、vitest 插件的许多规则现已完成。
• 支持通过 .oxlintrc.json 文件 进行配置，包括 嵌套配置文件，使用 extends 在文件间共享配置，对特定文件应用 overrides 等。
• 支持对 .astro、.svelte 和 .vue 文件中的 <script> 内容进行 lint 检查，无需额外配置。
• 允许对文件应用 自动修复 和建议。

更多规则，更高性能 ​

我们专注于使 Oxlint 功能更完整，支持许多最常用的 ESLint 规则和插件，同时也使 Oxlint 速度更快。

第一个 Oxlint 正式发布 (GA) 版本 总共有 205 条规则，其中 70 条默认启用。此 Beta 版本现在总共包含 502 条规则，其中 99 条默认启用（默认启用的规则数量增加了 41%）。

尽管添加了许多默认启用的新规则，Oxlint 现在的速度比以往任何时候都快。以下是一些流行仓库的 基准测试：

路线图 ​

Oxlint 最受请求的功能之一是对现有自定义 ESLint 插件的支持。我们一直忙于为此功能准备先决条件，并启用用 JavaScript 编写的快速 linter 插件。我们希望在下一次主要发布时提供此功能，并在不久的将来分享更多关于它的信息。

我们还计划继续改进 IDE/编辑器集成，更好地支持 VSCode、Zed、coc.nvim 和 IntelliJ 插件。

致谢 ​

如果没有超过 200 名项目贡献者，Oxlint Beta 版本是不可能实现的。

特别感谢：

• @cam314、@mysteryven 和 @shulaoda 用于实现许多复杂的 lint 规则、测试，并不断改进一切。
• @Sysix 用于维护 eslint-plugin-oxlint。
• @DonIsaac 用于改进配置、文档和网站，并代表 Oxc 参加 SquiggleConf 2024。
• @leaysgur 用于 RegExp 解析器和 JSDoc 插件。
• @u9g 和 @rzvxa 用于实现控制流图分析。
• @branchseer 用于实现多文件分析运行时。
• @camchenry 用于实现嵌套配置支持。

TL;DR: Oxlint 的第一个稳定版本已发布！与 ESLint 相比，性能提升了 50~100 倍，支持超过 500 条 ESLint 规则，并在 主要公司的使用情况 中得到验证，如 Shopify、Airbnb 和 Mercedes-Benz，你应该试一试。立即开始。

Oxlint 是一个基于 Rust 的 JavaScript 和 TypeScript 代码检查工具，旨在快速且易于采用。自 2023 年 12 月首次宣布以来，Oxlint 经历了显著的改进，现在发布了其第一个稳定版本 1.0。 除了稳定版本发布外，我们还想宣布 Oxlint 拥有一位专职维护者 Cameron，以及一个不断壮大的核心团队致力于维护和改进该代码检查工具。

实际影响 ​

我们对 Oxlint 的性能及其对真实大规模代码库的影响感到非常自豪，这降低了 CI 成本。

我们感谢 5,200 名早期采用者 以及以下公司和项目：

• Shopify，其前端平台团队在 Shopify 管理控制台中使用 Oxlint。
• Airbnb，他们在 126,000+ 个文件上使用多文件分析 oxc/no-barrel-file 和 import/no-cycle，在 CI 上仅需 7 秒即可完成。ESLint 对这些规则的实现会超时。
• Mercedes-Benz，他们观察到从 ESLint 切换到 Oxlint 后，lint 时间减少了 71%，某些项目甚至看到了高达 97% 的加速。
• 大型开源项目，从 Bun 等运行时到 Preact 等框架。

在我们发现的最大的仓库上，Oxlint 报告：

Finished in 22.5s on 264925 files with 101 rules using 10 threads.

基于发布在 X 和 Bluesky 上的真实案例， Oxlint 的运行速度约为每秒 10,000 个文件，具体取决于使用的线程总数。

快速开始 ​

Oxlint 非常适合那些希望开始检查代码而不想花费数小时配置工具的开发者。无需任何设置，你可以立即开始发现问题：

运行它，无需配置。

$ npx oxlint@latest

$ pnpm dlx oxlint@latest

$ yarn dlx oxlint@latest

$ bunx oxlint@latest

$ deno run npm:oxlint@latest

虽然不需要任何设置或配置，但 Oxlint 可以通过 .oxlintrc.json 文件进行配置，这对于大型项目或需要更多定制的项目非常有用。 此配置格式基于 ESLint v8 的平面配置（flat config），使得迁移变得简单且熟悉。 每个源文件都使用最近的适用配置进行 lint，你可以使用覆盖（overrides）来 targeting 特定的 glob 模式。 你还可以扩展共享配置以保持团队一致性。

对于已经使用 ESLint 的项目，可以使用 oxlint-migrate 将现有的 ESLint flat-config 文件迁移到 Oxlint。 此外，eslint-plugin-oxlint 可以在同时使用两个代码检查工具时禁用重叠的 ESLint 规则。 建议运行 oxlint && eslint 以受益于 Oxlint 更快的反馈周期。

有关如何使用 Oxlint 并将其与你的项目或编辑器集成的更详细说明，请查看 安装指南。

版本管理 ​

与发布运行时代码的库不同，代码检查工具只更改其返回的诊断信息。Oxlint 遵循语义化版本：

• 补丁版本：仅修复错误。
• 次要版本：扩展规则覆盖范围和诊断信息，无需更改配置。
• 主要版本：CLI 或配置更改，可能需要迁移。 请注意，如果新添加的规则发现了以前隐藏的问题，次要版本仍然可能会破坏你的 CI。在我们的 版本管理指南 中了解更多。

亮点 ​

全面的规则覆盖 ​

Oxlint 包含来自各种来源的超过 500 条规则：

• 完整的 ESLint 规则集，包括来自 typescript-eslint 的 TypeScript 特定规则（不包括类型检查规则）。
• 来自 eslint-plugin-unicorn、eslint-plugin-jsdoc、eslint-plugin-react、eslint-plugin-react-hooks、eslint-plugin-jest 和 eslint-plugin-import 的流行插件规则
• 独特的 Oxlint 规则，如 错误比较序列、常量比较 和 仅在递归中使用

灵活的配置 ​

通过 .oxlintrc.json 文件配置 Oxlint，支持：

• 适用于特定目录的嵌套配置
• 针对特定文件类型或位置的覆盖模式
• 共享配置扩展以保持团队一致性

编辑器集成 ​

一流的编辑器支持，扩展包括：

• VS Code
• IntelliJ IDEA 和 WebStorm
• Zed Editor
• 其他编辑器的语言服务器协议支持

有用的诊断信息 ​

Oxlint 旨在提供清晰、可操作的错误消息——不仅描述问题，还将其可视化并建议如何修复。

Oxlint 在终端中运行，带有详细的错误报告

基准测试 ​

我们的 基准测试 显示，在相同设置下，Oxlint 比 ESLint 快约 50~100 倍。

路线图 ​

Oxlint 1.0 只是一个开始！虽然它已稳定，但我们仍计划在未来版本中提供重要的功能和改进：

自定义规则 – JavaScript 插件支持即将推出，使团队能够编写与 Oxlint 架构无缝集成的自定义规则。

性能优化 – 持续改进解析和分析速度。

细粒度（每个 glob）配置 - ESLint v9 配置

致谢 ​

Oxlint 1.0 代表了 超过 200 位贡献者 的共同努力，他们塑造了这个项目。我们感谢每一个错误报告、功能请求和代码贡献。

特别感谢：

• @branchseer 实现了多文件分析运行时。
• @camc314、@mysteryven 和 @shulaoda 实现了许多复杂的 lint 规则、测试，并不断改进一切。
• @camchenry 实现了嵌套配置支持。
• @DonIsaac 改进了配置、文档和网站，并在 SquiggleConf 2024 上代表 Oxc。
• @leaysgur 开发了 RegExp 解析器和 JSDoc 插件。
• @Sysix 维护 eslint-plugin-oxlint 并对语言服务器和 VSCode 扩展做出了重大贡献。
• @u9g 和 @rzvxa 实现了控制流图分析。

加入社区 ​

我们很乐意听取你对 Oxlint 的反馈，并很高兴看到它如何帮助改善你的开发工作流。与我们联系：

• Discord：加入我们的 社区服务器 进行实时讨论
• GitHub：在 GitHub 讨论区 分享反馈
• Issues：在我们的 问题追踪器 上报告错误或请求功能

你的反馈推动着 Oxlint 的演进。

试一试 ​

要开始使用，请遵循 安装指南，或了解更多关于 Oxc 项目 的信息。

我们很高兴宣布 oxlint 中的类型感知 linting！

期待已久的 no-floating-promises 及相关规则现已到来。

此预览版旨在通过记录我们的决策过程和技术细节，与社区进行协作和讨论。

快速开始 ​

如果已配置 oxlint，请安装 oxlint-tsgolint 并使用 --type-aware 标志运行 oxlint：

pnpm add -D oxlint-tsgolint@latest
pnpm dlx oxlint --type-aware

如果未配置 oxlint 但想查看 no-floating-promises 的实际效果：

pnpm add -D oxlint-tsgolint@latest
pnpm dlx oxlint@latest --type-aware -A all -D typescript/no-floating-promises

例如，我们将看到：

 × typescript-eslint(no-floating-promises): Promises must be awaited, end with a call to .catch, end with a call to .then with a rejection handler or be explicitly marked as ignored with the `void` operator.
   ╭─[packages/rolldown/src/api/watch/watcher.ts:30:7]
29 │       await this.close();
30 │       originClose();
   ·       ──────────────
31 │     };
   ╰────

请访问我们的 使用指南 了解更多配置选项。

性能 ​

我们的测试显示，以前使用 typescript-eslint 需要一分钟才能运行的仓库，现在不到 10 秒即可完成。

这是通过利用 typescript-go 实现的， 它是用 Go 编写的 速度提升 10 倍的 TypeScript。

使用来自 oxc-ecosystem-ci 的项目：

类型感知 Linting ​

请参考 基于 Rust 的 JavaScript Linter：速度快，但目前没有类型化 Linting 以了解生态系统中类型感知 linting 的当前状态。

技术细节 ​

此新功能的核心是 oxc-project/tsgolint。

tsgolint 项目最初作为 typescript-eslint/tsgolint 进行原型设计。 然而，typescript-eslint 团队决定不为该原型分配开发资源，因为他们计划继续致力于使用 ESLint 进行类型化 linting 的 typescript-eslint 工作。

@boshen 联系了 @auvred，希望获得一个针对 oxlint 适配的、范围缩小的分支版本。 此版本将仅包含类型感知规则，而不需要完整 linter 所需的复杂配置解析。

@auvred 慷慨地提出在 Oxc 组织下继续其开发工作。

架构 ​

oxlint（用 Rust 编写）和 tsgolint（用 Go 编写）被编译为各自的二进制文件。

oxlint 作为 tsgolint 的“前端”，处理 CLI、路径遍历、忽略逻辑和诊断信息打印。

tsgolint 作为 oxlint 的后端，接受路径和配置作为输入，并输出结构化的诊断信息。

这创建了一个简单的管道：

oxlint CLI (returns paths + rules + configuration)
  -> tsgolint (returns diagnostics)
  -> oxlint CLI (prints diagnostics)

tsgolint ​

tsgolint 不通过公共 API 与 typescript-go 通信。

相反，它通过 shim 其内部 API 使其公开，从而编译 typescript-go。

所有类型感知规则都是直接针对这些 shim 化的 API 编写的。

虽然这不是访问内部结构的推荐方法，但它有效！

决策过程 ​

编写我们自己的类型检查器 ​

之前放弃的实现类型检查器的尝试包括：

• 我自己尝试 编写类型推断
• 集成 ezno 类型检查器 by @kaleidawave
• stc by @kdy1
• 社区中还有许多没有走得太远的尝试。

此外，还有正在进行的 Biome 2.0 及其自己的类型推断实现。

我们确定编写自己的类型推断器或类型检查器不可行，因为 难以跟上像 TypeScript 这样快速变化的目标。

与 TypeScript 编译器通信 ​

在 typescript-go 之前，项目通过将 AST 映射到 estree 或直接遍历 TypeScript AST，将插件接口添加到 TypeScript 的公共 API 中。例如：

• typescript-eslint
• tsslint
• tsl

我们还探讨了 与 oxlint 的进程间通信，但放弃了这个想法。

随着 typescript-go 的出现，TypeScript 团队 倾向于 编码 TypeScript AST 并通过进程间通信在 JavaScript 端解码。

虽然这些方法可行，但它们仍然会产生：

• 不同程度的性能问题，不适合 oxlint 的性能特征。
• 维护从 TypeScript AST 映射的 AST 的成本。

注意事项 ​

虽然 tsgolint 解决了性能问题，但还有其他技术挑战需要解决。

需要不同版本的 TypeScript ​

我们计划发布 typescript-go 版本的快照，并将其版本号与 TypeScript 对齐。 届时您将能够安装具有正确 TypeScript 版本的 oxlint-typescript。

这种方法的缺点是，如果 oxlint-tsgolint 需要更改，您可能需要升级 TypeScript。

tsgolint 的维护成本 ​

Shim TypeScript 的内部 API 带有一些风险。然而，TypeScript AST 及其访问者实际上相当稳定。 我们接受此风险，并将在升级 typescript-go 时修复破坏性变更。

我们的 typescript-go 版本每天同步。

性能问题 ​

tsgolint 目前在具有数百个项目或大量项目引用的大型单体仓库上表现不佳。

如果遇到 bug，它可能会因死锁而挂起或导致 OOM（内存不足）。

我们正在积极解决这些问题，对 typescript-go 进行性能分析并提交改进，使所有 typescript-go 用户受益。

我们的核心团队成员 @camc314 已经提交了 许多 PR，使 several code paths 显著更快。

v1.0 发布 ​

对于 tsgolint v1.0，我们将解决：

• 大型单体仓库的性能问题
• 能够配置单个规则
• 每个单独规则的正确性
• IDE 支持
• 整体稳定性

致谢 ​

我们要向以下各方表示感谢：

• TypeScript 团队创建了 typescript-go。
• typescript-eslint 团队给予的暖心支持。
• @auvred 创建了 tsgolint。
• @camchenry 完成了 oxlint + tsgolint 集成。
• @camc314 致力于性能问题的工作。

加入社区 ​

我们很希望听到您对 oxlint 和类型感知 linting 的反馈，并很高兴看到它如何帮助改善您的开发工作流程。

联系我们：

• Discord: 加入我们的 社区服务器 进行实时讨论
• GitHub: 在 GitHub Discussions 分享反馈
• Issues: 向 oxc 报告 oxlint bug，向 tsgolint 报告类型感知 linting bug。

下一步 ​

安装 oxlint：

pnpm add -D oxlint@latest oxlint-tsgolint@latest
pnpm dlx oxlint --init # generate .oxlintrc.json

或遵循 安装指南。

使用 --type-aware CLI 标志。

pnpm dlx oxlint --type-aware

并在 .oxlintrc.json 中尝试任何类型感知规则：

{
  "$schema": "./node_modules/oxlint/configuration_schema.json",
  "rules": {
    "typescript/await-thenable": "error",
    "typescript/no-array-delete": "error",
    "typescript/no-base-to-string": "error",
    "typescript/no-confusing-void-expression": "error",
    "typescript/no-duplicate-type-constituents": "error",
    "typescript/no-floating-promises": "error",
    "typescript/no-for-in-array": "error",
    "typescript/no-implied-eval": "error",
    "typescript/no-meaningless-void-operator": "error",
    "typescript/no-misused-promises": "error",
    "typescript/no-misused-spread": "error",
    "typescript/no-mixed-enums": "error",
    "typescript/no-redundant-type-constituents": "error",
    "typescript/no-unnecessary-boolean-literal-compare": "error",
    "typescript/no-unnecessary-template-expression": "error",
    "typescript/no-unnecessary-type-arguments": "error",
    "typescript/no-unnecessary-type-assertion": "error",
    "typescript/no-unsafe-argument": "error",
    "typescript/no-unsafe-assignment": "error",
    "typescript/no-unsafe-call": "error",
    "typescript/no-unsafe-enum-comparison": "error",
    "typescript/no-unsafe-member-access": "error",
    "typescript/no-unsafe-return": "error",
    "typescript/no-unsafe-type-assertion": "error",
    "typescript/no-unsafe-unary-minus": "error",
    "typescript/non-nullable-type-assertion-style": "error",
    "typescript/only-throw-error": "error",
    "typescript/prefer-promise-reject-errors": "error",
    "typescript/prefer-reduce-type-parameter": "error",
    "typescript/prefer-return-this-type": "error",
    "typescript/promise-function-async": "error",
    "typescript/related-getter-setter-pairs": "error",
    "typescript/require-array-sort-compare": "error",
    "typescript/require-await": "error",
    "typescript/restrict-plus-operands": "error",
    "typescript/restrict-template-expressions": "error",
    "typescript/return-await": "error",
    "typescript/switch-exhaustiveness-check": "error",
    "typescript/unbound-method": "error",
    "typescript/use-unknown-in-catch-callback-variable": "error"
  }
}

今年早些时候，我们向社区征求了意见， 以便为 Oxlint 支持自定义 JS 插件的设计提供参考。今天，我们很高兴地宣布经过数月 的研究、原型设计，以及最终的构建成果：

Oxlint 支持用 JS 编写的插件！

主要特性 ​

• 与 ESLint 兼容的插件 API。Oxlint 将能够运行许多现有的 ESLint 插件而无需修改。
• 另一种略有不同的 API，可实现更好的性能。

这是什么以及不是什么 ​

此预览版仅仅是个开始。重要的是要注意：

• 此初始版本并未实现 ESLint 插件 API 的全部功能。
• 性能不错，但会变得更加出色——我们有许多优化正在计划中。

用于代码检查规则的最常用 API 已实现，因此许多现有的 ESLint 规则已经可以工作。 但与 token 相关的 API 尚未包含，因此风格（格式化）规则将无法工作。

我们邀请用户试用一下，提供反馈，并为下一阶段的开发优先事项提供参考。

本文涵盖内容 ​

1. 如何使用它。
2. 接下来会有什么。
3. 一些技术细节，使我们能够采用“鱼与熊掌兼得”的方法，既提供 ESLint 兼容性 又 提供卓越的性能。

快速开始 ​

在项目中安装 Oxlint：

pnpm add -D oxlint

编写自定义 JS 插件：

// plugin.js

// 最简单的规则 - 禁止 debugger
const rule = {
  create(context) {
    return {
      DebuggerStatement(node) {
        context.report({
          message: "No debugger!",
          node,
        });
      },
    };
  },
};

const plugin = {
  meta: {
    name: "best-plugin-ever",
  },
  rules: {
    "no-debugger": rule,
  },
};

export default plugin;

创建启用插件的配置文件：

// .oxlintrc.json
{
  "jsPlugins": ["./plugin.js"],
  "rules": {
    "best-plugin-ever/no-debugger": "error"
  }
}

添加一个待检查的文件：

// foo.js
debugger;

运行 Oxlint：

pnpm oxlint

预期看到：

 x best-plugin-ever(no-debugger): No debugger!
  ,-[foo.js:1:1]
1 | debugger;
  : ^^^^^^^^^
  `----

有关编写插件的更多详情，请参阅 文档。

替代 API ​

Oxlint 还提供了一种略有不同的 API，可实现更好的性能。

此替代 API 生成的插件既兼容 ESLint，也兼容 Oxlint。

示例规则：标记包含超过 5 个类声明的文件：

ESLint 版本 ​

const rule = {
  create(context) {
    let classCount = 0;

    return {
      ClassDeclaration(node) {
        classCount++;
        if (classCount === 6) {
          context.report({ message: "Too many classes", node });
        }
      },
    };
  },
};

替代 API 版本 ​

import { defineRule } from "oxlint";

const rule = defineRule({
  createOnce(context) {
    // 定义计数器变量
    let classCount;

    return {
      before() {
        // 在遍历每个文件的 AST 之前重置计数器
        classCount = 0;
      },
      // 与之前相同
      ClassDeclaration(node) {
        classCount++;
        if (classCount === 6) {
          context.report({ message: "Too many classes", node });
        }
      },
    };
  },
});

差异 ​

1. 将规则对象包裹在 defineRule(...) 中。

- const rule = {
+ const rule = defineRule({

2. 使用 createOnce 代替 create。

-   create(context) {
+   createOnce(context) {

3. 将任何每文件设置从 create 主体移动到 before 钩子。

-     let classCount = 0;
+     let classCount;

      return {
+       before() {
+         classCount = 0; // 重置计数器
+       },
        ClassDeclaration(node) {
          classCount++;
          if (classCount === 6) {
            context.report({ message: "Too many classes", node });
          }
        },
      };
    },
  });

这是唯一的显著差异——create（ESLint 的方法）为每个文件 重复调用， 而 createOnce 仅调用一次。

所有其他 API 的行为与 ESLint 完全相同。

为何此替代 API 有可能大幅提高性能的原因在 文档 中解释。

性能 ​

如上所述，在 Oxlint JS 插件的此初始预览版中，性能并非我们的关注重点。 我们的主要目标是填充足够的 API，使 JS 插件在实际项目中有用， 并收集早期采用者的反馈。

目前的性能尚可，但绝不出色。

然而——我们认为这是重点——我们下一个 版本的原型表明， 一旦加入各种优化（参见 幕后技术）， 我们确定的架构设计能够实现卓越 的性能。

我们将在未来几个月内应用这些优化，用户将看到相比当前版本有多倍的速度提升。

话虽如此，即使没有这些优化，Oxlint 的性能仍然具有竞争力。

Oxlint 与 ESLint 检查中型 TypeScript 项目 vuejs/core 的对比：

hyperfine -i --warmup 3 \
  './node_modules/.bin/oxlint --silent' \
  './node_modules/.bin/oxlint -c .oxlintrc-with-custom-plugin.json --silent' \
  'USE_CUSTOM_PLUGIN=true ./node_modules/.bin/eslint .' \
  'USE_CUSTOM_PLUGIN=true ./node_modules/.bin/eslint . --concurrency=auto'

在此示例中，向 Oxlint 添加一个简单的 JS 插件确实会产生显著开销，但 Oxlint 仍然比 ESLint 快 15 倍，即使使用 ESLint 新的多线程运行器。

显然，更复杂的 JS 插件，或许多插件，将具有更高的性能成本。

特性 ​

Oxlint 支持大多数通常用于仅依赖 AST 检查的插件/规则中的 ESLint API。 这包括大多数“修复代码”类规则。

它尚未支持基于 token 的 API，因此风格（格式化）规则暂时无法工作。

已支持 ​

• AST 遍历
• AST 探索（node.parent, context.sourceCode.getAncestors）
• 修复
• 选择器（ESLint 文档）
• SourceCode API（例如 context.sourceCode.getText(node)）

尚未支持 ​

• 语言服务器 (IDE) 支持
• 规则选项
• 建议
• 作用域分析（自 v1.25.0 起 已实现）
• 与 token 和注释相关的 SourceCode API（例如 context.sourceCode.getTokens(node)）
• 控制流分析

接下来会有什么 ​

在未来几个月内，我们将：

1. 完善插件 API 覆盖面 ​

目标是支持 100% 的 ESLint 插件 API 覆盖面，以便 Oxlint 最终能够运行任何 ESLint 插件而无需修改。

2. 提升性能 ​

性能已经不错，但我们在原型设计期间证明了进一步优化会带来许多显著的性能提升。我们将应用它们， 使 Oxlint 中的 JS 插件运行速度尽可能接近 Rust 速度。

幕后技术 ​

本文的其余部分对于使用 Oxlint 的 JS 插件并非必需。但如果你对我们实现方式的 技术细节感兴趣，请继续阅读...

大问题：是否兼容 ESLint？ ​

今年早些时候，我们向社区提出的问题 是 Oxlint 是否应该旨在实现与 ESLint 兼容的插件 API。

显然，就熟悉度和从 ESLint 迁移的便利性而言，与 ESLint 兼容的接口是理想的。

然而，Oxlint 以其卓越的性能而闻名，过多妥协并不可取。

过去几个月我们原型设计工作的主要目标是量化性能 与 ESLint 兼容性之间的权衡，并调查是否存在一种“鱼与熊掌兼得”的解决方案，能够同时满足两者—— 提供与 ESLint 兼容的 API 和 可接受的性能（这里的“可接受”意味着非常快！）

我们相信通过结合不同的方法，我们找到了一种满足两者需求的方式。

替代 API ​

请参阅 文档 中的解释， 了解为何此 API 能释放更高性能的潜力。

原始传输 ​

像 Oxc 这样的工具将 JS/TS 文件的代码表示为"AST" （抽象语法树）。 AST 非常大——比它们代表的源代码大得多。

通常，JS 与 Rust 等原生语言之间进行高性能互操作的最大障碍是 在“两个世界”之间传输如此大型数据结构所涉及的序列化 和反序列化。

在 JS 和 Rust 之间移动 AST 最简单和最常见的方法是：将 AST 序列化为 JSON，作为字符串发送到 JS， 然后使用 JSON.parse 再次“还原”它。但这非常慢。通常这些 转换的成本如此之高，以至于它们大大超过了首先使用原生代码所带来的性能增益。 其他序列化格式比 JSON 更高效，但它们仍然有相当大的开销。

我们开发了一种“原始传输”方案，通过使用 Rust 的原生内存布局作为序列化格式，完全消除了序列化（有关其工作原理的更多详情见 此处）。

“原始传输”是当前 JS 插件实现的基础。

惰性反序列化 ​

良好性能的第二大敌人，特别是在工作线程中跨多个 CPU 核心运行 JS 时， 是垃圾回收器。你创建的每个对象也需要被销毁以回收其内存。 在 JS 中，这是垃圾回收器的工作。像 V8 这样的 JS 引擎经过高度优化，但垃圾回收 仍然是一个昂贵的过程，并且 GC 会“窃取”实际工作负载的 CPU 资源。

我们原型化了一个 AST 访问器，它惰性 地反序列化 AST，并且只反序列化实际上需要 的 AST 部分。

例如，如果你的 lint 规则与类声明有关，此访问器将飞过大部分 AST 而不做太多事情， 并且只会为 ClassDeclaration AST 节点创建 JS 对象，然后将这些对象传递给规则的代码 进行处理。对于其余的 AST（变量声明、if 语句、函数等），根本不需要创建 节点对象。

这有 2 个效果：

1. 原始传输将序列化成本降为零。惰性也大大减少了另一面 （反序列化）。
2. 大大降低了垃圾回收器压力。

Deno 采用了类似的方法，这在 Marvin Hagemeister 的博客文章 中解释得非常精彩，并且 Deno lint 有一个非常高效的实现。

然而，我们发现正是惰性反序列化与“原始传输”的结合提供了真正 好的 性能。我们的测试发现，消除了这两项开销后，JS 插件可以以更快的速度运行。

此优化尚未包含在当前版本的 JS 插件中。我们将在未来版本中实现它。

试一试！ ​

请尝试一下 JS 插件并报告您的体验。所有反馈——无论是正面的还是负面的——我们都感激不尽。

特别是，如果您发现 Oxlint 缺少您的插件工作所需的一些 API，请告诉我们。我们将在未来几个月内填补 API 的空白，并将优先考虑需求最大的那些。

祝您 lint 愉快！

编辑：2025 年 10 月 18 日 ​

这篇博客文章最初于 10 月 9 日发布的版本包含了一些基准测试结果，显示 Oxlint JS 插件的性能比实际情况要好得多。这是由于 Oxlint 中的一个 bug 造成的，该 bug 导致在某些情况下，当配置包含 overrides 时，许多文件会跳过 JS 插件。这个 bug 导致我们引用的基准测试中 JS 插件的性能被严重高估。

我们为这个错误真诚地道歉，并感谢 Herrington Darkholme 指出了这个错误。

我们很高兴宣布 Oxfmt 的 Alpha 版本发布，这是一个基于 Rust 构建的、兼容 Prettier 的代码格式化器。首个版本专注于 JavaScript 和 TypeScript，对其他语言的支持即将推出。

Oxfmt 的设计旨在实现以下目标：

• 性能： 初次运行无缓存情况下，比 Prettier 快 30 倍以上，比 Biome 快 3 倍以上（基准测试）。
• 兼容性： 兼容 Prettier，因此您可以轻松在现有项目中采用 Oxfmt。
• 开发者体验： 即将推出的功能包括导入排序、扩展格式化选项以及对 Prettier 插件的支持。

快速开始 ​

将 oxfmt 添加到您的项目：

npm add -D oxfmt@latest

pnpm add -D oxfmt@latest

yarn add -D oxfmt@latest

bun add -D oxfmt@latest

deno add -D npm:oxfmt@latest

Oxfmt 遵循 Prettier 的配置格式。如果您使用 JSON 配置文件运行 Prettier，可以将其重命名为 .oxfmtrc.jsonc：

cp .prettierrc.json .oxfmtrc.jsonc

您也可以从这个 .oxfmtrc.jsonc 配置示例开始：

{
  "$schema": "./node_modules/oxfmt/configuration_schema.json",
  // 如果从 Prettier 迁移请使用 80；100 是 Oxfmt 的默认值！
  "printWidth": 80,
  "ignorePatterns": [] // 与 `.prettierignore` 相同
}

接下来，将 oxfmt 添加到您的 package.json scripts 中：

"scripts": {
  "format": "oxfmt"
}

或者，参阅 安装指南 获取详细说明。

性能 ​

Oxfmt 速度极快。我们在 Outline 仓库上的基准测试结果显示：

• 比无缓存的 Prettier 实验性 CLI 快 30 倍以上
• 比通过 @prettier/plugin-oxc 使用 Oxc 解析器的 Prettier 快 20 倍以上
• 比另一个基于 Rust 的格式化器 Biome 快 3 倍以上

有关详细的基准测试设置，请参阅以下仓库：

oxc-project/bench-formatter
https://github.com/oxc-project/bench-formatter

设计 ​

Oxc 团队优先考虑与现有生态系统的兼容性，使得迁移变得简单直接，即使是大型代码库。

代码格式化结果 ​

Oxfmt 与 Prettier 的 JavaScript 格式化结果一致。如果您今天迁移到 Oxfmt，与 Prettier 相比应该不会看到任何格式化差异。

从较旧版本的 Prettier 迁移时，您可能会看到细微差异（参见迁移示例），因为我们发现了 Prettier 格式化可以改进的地方。我们一直积极与 Prettier 团队合作，直接向 Prettier 提交错误报告和拉取请求。其中许多改进已纳入最近的 Prettier 3.7 版本中。

Oxfmt 目前通过了大约 95% 的 Prettier JavaScript 和 TypeScript 测试，我们希望随着时间的推移与 Prettier 团队共同努力，使格式化结果趋于一致。

默认 printWidth: 100 ​

我们选择 printWidth: 100 作为默认行长度，而不是 Prettier 的 80。我们的原因包括：

• TypeScript 代码由于类型注释往往比 JavaScript 更长。
• 导入语句通常包含许多项。
• 更大的屏幕提供更多的水平空间。
• 产生的 LLM tokens 略少。

虽然 Oxfmt 保持与 Prettier 兼容，但它使用不同的默认打印宽度 100 个字符。如果您想在从 Prettier 迁移时避免大的差异，请显式将打印宽度设置为 80。

ignorePatterns ​

虽然 Oxfmt 支持 .prettierignore，但它也支持 ignorePatterns 配置选项，以便将所有配置合并到一个文件中。

配置 ​

Prettier JSON 配置文件与 Oxfmt 兼容。在最简单的情况下，迁移配置如下所示：

cp .prettierrc.json .oxfmtrc.jsonc

如果您的编辑器支持 JSON 语言服务器，您可以在将 oxfmt 添加到 devDependencies 后使用此最小模板：

{
  "$schema": "./node_modules/oxfmt/configuration_schema.json",
  "ignorePatterns": []
}

虽然在此 Alpha 版本中我们尚未支持 Prettier 的所有配置选项，但我们支持以下主要选项：printWidth、tabWidth、useTabs、semi、singleQuote、quoteProps、jsxSingleQuote、trailingComma、bracketSpacing、objectWrap、bracketSameLine、arrowParens、endOfLine 和 singleAttributePerLine。

在我们的 文档 中查看所有选项。

终端输出 ​

Oxfmt 的默认行为等同于 prettier . --write，提供与 cargo fmt 相同的用户体验且不产生输出。您可以使用 --check 来显示格式化差异并在 CI 流程中强制使用 oxfmt。

Beta 版本发布计划 ​

以下是我们对 Beta 版本的计划：

• 支持更多文件格式 - 如 .json 文件
• 添加对嵌入式语言格式化的支持 - js 中的 css 或 js 中的 graphql
• 内置排序和美学功能，例如 导入排序
• Prettier 插件
• Oxfmt 的 Node.js API
• 禁用文件末尾的换行符
• --migrate prettier
• … 以及您的功能请求

您可以在此处跟踪我们迈向 Beta 版本的进度：

Formatter Beta · Milestone #15 · oxc-project/oxc
https://github.com/oxc-project/oxc/milestone/15

我们还计划在未来版本中放宽一些格式化意见。

下一步 ​

请在 Oxfmt 文档 中查看完整的安装指南。

报告问题 ​

对于格式化差异，请参阅 https://github.com/oxc-project/oxc/discussions/14669。 此外，已知问题通过 标签 区分。

如果您发现任何其他问题，请在 GitHub 上使用 专用模板 创建问题。

加入社区 ​

RFC: Formatter · oxc-project/oxc · Discussion #13608
https://github.com/oxc-project/oxc/discussions/13608

我们欢迎您的反馈，帮助使 Oxfmt 变得更好！

致谢 ​

Oxfmt 基于 biome_formatter 基础设施的 fork 构建，我们要感谢 Biome 团队，尤其是 @ematipico 和 @MichaReiser。我们还要感谢 Prettier 团队和 @fisker 在格式化兼容性方面与我们合作。

我们很高兴地宣布 Oxlint 中类型感知 linting 的 Alpha 版本发布！

概述 ​

继我们 8 月的技术预览 之后，我们很高兴地宣布类型感知 linting 已达到 Alpha 状态。这一里程碑带来了稳定性、可配置性和规则覆盖范围的显著改进。

类型感知 linting 支持强大的规则，如 no-floating-promises、no-misused-promises 和 await-thenable，它们利用 TypeScript 的类型系统来捕捉 bug。现在已有 43 条类型感知规则可用，您可以在运行时错误发生之前捕捉到整个类别的错误。

本文内容：

• 快速开始 - 几分钟内开始使用类型感知 linting
• 性能 - 查看类型感知 linting 比 ESLint 快多少
• 技术预览以来有哪些新功能 - 新功能和改进
• 技术细节 - 类型感知 linting 如何在底层工作
• 下一步计划 - Beta 版本的即将改进

快速开始 ​

安装 oxlint 和 oxlint-tsgolint，然后使用 --type-aware 标志运行：

npm add -D oxlint oxlint-tsgolint@latest
npx oxlint --type-aware

pnpm add -D oxlint oxlint-tsgolint@latest
pnpm oxlint --type-aware

yarn add -D oxlint oxlint-tsgolint@latest
yarn oxlint --type-aware

bun add -D oxlint oxlint-tsgolint@latest
bunx oxlint --type-aware

要尝试特定的类型感知规则而不使用其他配置（oxlint-tsgolint 必须已经全局或本地安装）：

npx oxlint --type-aware -A all -D typescript/no-floating-promises

pnpx oxlint --type-aware -A all -D typescript/no-floating-promises

yarn oxlint --type-aware -A all -D typescript/no-floating-promises

bunx oxlint --type-aware -A all -D typescript/no-floating-promises

有关更多配置选项，请参阅我们的 使用指南。

性能 ​

基准测试是在 MacBook Pro M2 Max 12 核心（8 个性能核心和 4 个能效核心）上进行的。

我们的性能测试显示，带有类型感知 linting 的 oxlint 比带有 typescript-eslint 的 eslint 快大约 10 倍。查看我们的 性能基准测试 了解更多详情。

Oxlint 还可以在 lint 的同时用于类型检查您的代码库。这避免了重复工作，因为许多类型信息已经在类型感知 linting 期间计算好了。

技术预览以来有哪些新功能？ ​

支持在 lint 过程中进行类型检查 ​

tsgolint 现在支持在 lint 时发出 TypeScript 的类型检查错误。由于类型感知规则已经需要检查文件中的所有类型，我们能够使用这些现有的类型信息而不是丢弃它们。这意味着在某些情况下，可以完全跳过单独的类型检查命令（例如 tsc --noEmit），减少在 CI 中花费在 linting 和类型检查上的总时间。

这是一个实验性功能，但您可以通过向 oxlint 命令添加 --type-check 和 --type-aware 标志来启用它：

$ oxlint --type-aware --type-check

  × typescript(TS2322): Type 'number' is not assignable to type 'string'.
   ╭─[index.ts:1:7]
 1 │ const message: string = 1
   ·       ───────
   ╰────

支持在 oxlint 中配置规则 ​

在 tsgolint 中运行的类型感知规则可以像任何其他 lint 规则一样在 oxlint 中配置。例如，您可以配置 no-floating-promises 规则以允许某些安全调用或忽略 void：

{
  "rules": {
    "typescript/no-floating-promises": [
      "error",
      {
        "ignoreVoid": true,
        "allowForKnownSafePromises": [
          { "from": "file", "name": "SafePromise" },
          { "from": "lib", "name": "PromiseLike" }
        ]
      }
    ]
  }
}

配置选项与 typescript-eslint 支持的选项保持一致，文档可以在每个规则的配置部分找到（例如 no-floating-promises）。

支持行内禁用注释 ​

在 tsgolint 中运行的规则现在可以通过在文件中或行上放置注释来禁用，类似于任何其他 oxlint 规则：

/* oxlint-disable typescript/no-floating-promises */

// oxlint-disable-next-line typescript/no-floating-promises
[1, 2, 3].map(async (x) => x + 1);

支持更多规则 ​

我们继续致力于从 typescript-eslint 移植流行规则，您现在可以通过 oxlint 使用它们。tsgolint 与 oxlint 结合，目前支持 43 条类型感知规则。

自初始预览以来，还添加了对以下规则的支持：

• no-deprecated（最常请求的规则之一）
• prefer-includes
• strict-boolean-expressions

现在会报告 TypeScript 程序诊断信息 ​

以前，如果 TypeScript 无法创建和解析程序，这些错误不会被报告，导致人们对为什么 linting 不起作用感到困惑。现在，我们将报告创建程序时的任何问题作为诊断信息，包括 tsconfig.json 文件中的配置问题。

例如，如果 tsconfig.json 文件包含 baseUrl，这将报告为错误，因为 baseUrl 已在 TypeScript v7.0 中移除：

$ oxlint --type-aware

  × typescript(tsconfig-error): Invalid tsconfig
   ╭─[tsconfig.json:4:3]
 3 │     "compilerOptions": {
 4 │         "baseUrl": ".",
   ·         ─────────
 5 │         "experimentalDecorators": true,
   ╰────
  help: Option 'baseUrl' has been removed. Please remove it from your configuration.
        See https://github.com/oxc-project/tsgolint/issues/351 for more information.

类型感知规则的自动修复 ​

类型感知规则现在支持通过 --fix 标志进行自动修复。当您运行 oxlint --type-aware --fix 时，来自 tsgolint 的可修复诊断信息将像常规 oxlint 修复一样应用。这使修复工作流程与非类型感知规则完全一致。

技术细节 ​

架构 ​

Oxlint 中的类型感知 linting 使用独特的双二进制架构：

oxlint CLI (Rust)
  ├─ Handles file traversal, ignore logic, and diagnostics
  ├─ Runs non-type-aware rules and custom JS plugins
  ├─ Passes paths and configuration to tsgolint
  └─ Formats and displays results

tsgolint (Go)
  ├─ Uses typescript-go directly for type checking
  ├─ Executes type-aware rules
  └─ Returns structured diagnostics

这种设计在通过 typescript-go 利用 TypeScript 类型系统的同时，保持了 Oxlint 核心的快速。前端 - 后端分离意味着 oxlint 控制用户体验，而 tsgolint 处理类型分析的繁重工作。

TypeScript 兼容性 ​

tsgolint 基于 typescript-go，这是微软基于 Go 的重写版本，将成为 TypeScript v7.0。有关 TypeScript 7 进度的更多详情，请参阅 官方 TypeScript 博客文章。这意味着您可能会遇到一些不再支持的功能。

重要的兼容性说明：

• 仅支持 TypeScript 7.0+ 功能
• 不支持 7.0 之前的语法和已弃用的功能
• 遗留的 tsconfig.json 选项（如 baseUrl）已在 TypeScript 7.0 中移除

如果您正在使用 TypeScript 6.0 或更早版本的已弃用功能，您需要先迁移代码库。请参阅 TypeScript 迁移指南 以帮助更新已弃用的 tsconfig 选项。

实现细节 ​

tsgolint 不使用 typescript-go 的公共 API。相反，它通过 shimming 内部 API 来编译 typescript-go，使它们可访问。我们积极跟踪 typescript-go 更新并根据需要修复破坏性变更。

我们的 typescript-go 分支使用 renovatebot 定期同步，确保我们保持最新的改进和修复。一旦 TypeScript 7.0 正式发布，我们将跟踪稳定版本而不是主分支的顶端。

下一步计划 ​

我们正在积极致力于以下改进以发布 Beta 版本：

• 支持更多规则 - 目前我们支持 typescript-eslint 中 59 条类型感知规则中的 43 条。随着我们走向 Beta 发布，我们计划继续扩大规则覆盖范围。
• 性能和内存使用改进 - 我们将继续优化性能，特别是对于非常大的 monorepos。

致谢 ​

我们想向以下各方表示感谢：

• TypeScript 团队创建了 typescript-go。
• typescript-eslint 团队给予的暖心支持。
• @auvred 创建了 tsgolint。
• @camchenry 持续进行的性能优化工作，以及实现了规则选项支持。

试一试 ​

准备好开始了吗？前往上方的 快速开始 部分安装并运行类型感知 linting。

我们很希望听到您对类型感知 linting 的反馈，也很兴奋看到它如何帮助改善您的开发工作流。

联系我们：

• Discord：加入我们的 社区服务器 进行实时讨论
• GitHub：在 GitHub 讨论区 分享反馈
• 问题：将 oxlint 的 bug 报告给 oxc，将类型感知 linting 的 bug 报告给 tsgolint。

我们很高兴地宣布 Oxfmt 已进入 Beta 阶段。

Oxfmt 是一个基于 Rust 驱动、与 Prettier 兼容的代码格式化程序，专为 JavaScript 生态系统构建。它旨在与现代工具链完全兼容，同时显著提升性能。

在基准测试中，在无缓存的首次运行中，Oxfmt 的速度比 Prettier 快 30 倍以上，比 Biome 快 3 倍。查看完整的 基准测试 结果。

自 12 月的 Alpha 版本发布以来，我们扩展了对更多文件格式的支持，添加了嵌入式语言格式化，引入了导入排序，集成了 Tailwind CSS 支持，并带来了许多稳定性和兼容性改进。

Oxfmt 已经在生态系统中得到了广泛采用。使用 Oxfmt 的项目包括：openclaw/openclaw、vuejs/core、vercel/turborepo、huggingface/huggingface.js、getsentry/sentry-javascript、npmx-dev/npmx.dev 以及更多。

快速开始 ​

将 oxfmt 安装为开发依赖：

pnpm add -D oxfmt

将脚本添加到 package.json：

{
  "scripts": {
    "fmt": "oxfmt",
    "fmt:check": "oxfmt --check"
  }
}

格式化文件：

pnpm run fmt

检查格式化而不写入文件：

pnpm run fmt:check

从 Prettier 迁移 ​

安装、迁移配置并重新格式化，只需一条命令：

pnpm add -D oxfmt && pnpm oxfmt --migrate prettier && pnpm oxfmt

完整迁移指南，请参阅 从 Prettier 迁移。

AI 迁移提示词 ​

或者，你可以将此提示词复制到你的 AI 编程助手以迁移你的项目：

按照 https://oxc.rs/docs/guide/usage/formatter.html 将此项目从 Prettier 迁移到 Oxfmt：
1. 安装 oxfmt 并运行 `oxfmt --migrate prettier`
2. 更新 package.json 脚本以使用 oxfmt
3. 更新 CI 工作流以使用 `oxfmt --check`
4. 更新 lint-staged 以使用 `oxfmt --no-error-on-unmatched-pattern`
5. 运行 oxfmt 重新格式化所有文件
6. 卸载 prettier 及相关包
7. 更新编辑器设置以支持 oxfmt
8. 如果 CONTRIBUTING.md、AGENTS.md 或 CLAUDE.md 中提到了 prettier，请更新它们

更多详细说明，请查看 Oxfmt 文档。

自 Alpha 版本以来的新功能亮点 ​

100% Prettier 兼容性 ​

Oxfmt 现在通过了 Prettier 100% 的 JavaScript 和 TypeScript 一致性测试。对于少数剩余的格式化不一致之处，我们已 向 Prettier 团队报告 并正在协作以达成预期行为的一致。

这意味着你可以放心地从 Prettier 迁移到 Oxfmt，确信你的代码将被相同地格式化。如果你遇到任何未覆盖的情况，请 报告它们。

更多文件格式支持 ​

Oxfmt 现在支持格式化 JavaScript、JSX、TypeScript、TSX、JSON、JSONC、JSON5、YAML、TOML、HTML、Angular、Vue、CSS、SCSS、Less、Markdown、MDX、GraphQL、Ember 和 Handlebars。这意味着你可以为整个项目使用单一格式化程序。

Tailwind CSS 集成 ​

支持对 JS/TS 和非 JS/TS 文件进行自动 Tailwind CSS 类排序。prettier-plugin-tailwindcss 的功能已内置，因此不再需要该插件。

导入排序 ​

内置的 导入排序 现已可用，带有可配置选项：

• ignoreCase - 不区分大小写排序
• sortSideEffects - 排序副作用导入
• newlinesBetween - 控制导入组之间的空行
• groups - 自定义排序顺序组
• customGroups - 定义自定义分组规则

更多选项，请参阅 完整参考。

package.json 排序 ​

默认启用自动 package.json 字段排序，保持你的 package.json 文件一致的组织结构。

嵌入式语言格式化 ​

格式化 嵌入在模板字面量中的代码：

• 具有 styled-components 类似语法的 CSS-in-JS，styled-jsx 和 CSS prop 支持
• Angular @Component 模板和样式

Node.js API ​

现在可以使用编程式 API：

import { format, type FormatOptions } from "oxfmt";

const input = `let a=42;`;
const options: FormatOptions = {
  semi: false,
};

const { code } = await format("a.js", input, options);
console.log(code); // "let a = 42"

CLI 变更 ​

• --init - 引导生成新的配置文件
• --migrate prettier - 从 Prettier 配置迁移
• --migrate biome - 从 Biome 配置迁移
• --stdin-filepath - 指定 stdin 输入的文件路径
• 支持 Glob 模式展开 - oxfmt './packages/**/*.{js,jsx}'

配置变更 ​

• overrides - 将不同选项应用于特定文件模式
• insertFinalNewline - 控制尾部换行
• 支持 .editorconfig 中的 insert_final_newline

编辑器支持 ​

Oxfmt 适用于所有支持的编辑器：VS Code、Cursor、Zed、IntelliJ IDEA、WebStorm、Neovim 以及任何支持 LSP 的编辑器。

路线图 ​

我们正在持续改进 Oxfmt 以迈向稳定版发布：

• 支持 Prettier 插件
• 改进 xxx-in-js 格式化
• 稳定性
• 性能优化

下一步 ​

请参阅 Oxfmt 文档 中的完整安装指南。

报告问题 ​

对于格式化差异，请参阅 格式化差异讨论。

加入社区 ​

我们很乐意听取你对 Oxfmt 的反馈。联系我们：

• Discord：加入我们的 社区服务器 进行实时讨论
• GitHub：在 Formatter RFC 上分享反馈
• Issues：在 问题追踪器 上报告错误或请求功能

Oxlint 的 JavaScript 插件已达到 Alpha 阶段 - 我们预计 80% 的 ESLint 用户现在可以切换到 Oxlint，并且能够“开箱即用”。

Oxlint 已经用 Rust 实现了超过 650 条流行的 lint 规则，以原生速度运行。JS 插件填补了空白 - 一个兼容 ESLint 的插件 API，让你可以在 Oxlint 中运行现有的 ESLint 插件并编写你自己的自定义规则。大多数规则享有原生性能，其余规则拥有完全的灵活性。

自从去年 首次技术预览 以来，我们完善了几乎整个 ESLint 插件 API，添加了 TypeScript 插件支持、自动修复、IDE 集成以及 重大的性能提升。

这意味着许多团队可以用 Oxlint 替换 ESLint，而无需重写他们的 lint 规则。

这个 Alpha 版本标志着我们认为 JS 插件已准备好在真实世界项目中采用的节点。

大多数项目应该会发现 Oxlint 现在可以作为 ESLint 的直接替代品，迁移简单，并且 lint 时间大幅减少。

功能 ​

• 无需修改即可运行大多数现有的 ESLint 插件。
• 使用 JavaScript 或 TypeScript 编写你自己的自定义 lint 规则。
• 从 JS 插件规则获得自动修复和建议。
• 通过语言服务器在 IDE 中实时查看 JS 插件诊断。

它有多可靠？ ​

Oxlint JS 插件支持针对 ESLint 本身的完整测试套件进行了测试，也针对广泛的 ESLint 插件进行了测试，包括：

* 不包括类型感知规则

如果插件不在上面的列表中，它很可能仍然可以工作 - 只是尚未包含在 我们的合规性测试套件 中。

ESLint 自己的测试覆盖了整个 API 表面，所以 100% 的通过率让我们有信心覆盖了边界情况以及正常路径。请尝试一下并告诉我们反馈！

Oxlint 已经被许多公司和项目在生产环境中使用，包括 Midjourney、Preact、Posthog、Outline 和 Actual。

它目前还不能做什么 ​

• 对前端框架自定义文件格式的支持有限（例如 Svelte、Vue、Angular）- 今年晚些时候推出。
• 没有自定义类型感知规则（TypeScript-ESLint 的规则已经通过 类型感知 lint 内置到 Oxlint 中）。
• 一些用户发现 Windows 上的体验欠佳。内存不足错误是 一个已知问题，特别是在 Windows 上。我们正在解决。与此同时，如果你遇到这个问题，我们建议在可行的情况下在 WSL 中运行 Oxlint。

你可以在 跟踪问题 上关注我们填补这些空白的进展。

开始使用 ​

将 oxlint 安装为开发依赖：

pnpm add -D oxlint

在 package.json 中添加脚本：

{
  "scripts": {
    "lint": "oxlint"
  }
}

创建配置文件（或使用 我们的迁移工具）：

{
  "jsPlugins": ["eslint-plugin-testing-library"],
  "rules": {
    "testing-library/no-render-in-lifecycle": "error"
  }
}

Lint 你的项目：

pnpm run lint

从 ESLint 迁移 ​

大多数项目应该会发现从 ESLint 迁移很简单。

最简单的途径是通过 @oxlint/migrate 工具。

npx @oxlint/migrate eslint.config.js

或者让你的编码代理使用 migrate-oxlint 技能 为你完成。

查看更多详情请参阅 迁移指南。

ESLint 规则 ​

Oxlint 已经原生实现了大多数 ESLint 的内置规则，用 Rust 重写，但并非所有规则都已实现。

为了弥补这一差距，我们提供了 oxlint-plugin-eslint，其中包含所有 ESLint 内置规则，打包为 Oxlint JS 插件。

这解锁了诸如 no-restricted-syntax 之类的规则，这些规则尚未在 Oxlint 中原生实现。

{
  "jsPlugins": ["oxlint-plugin-eslint"],
  "rules": {
    // 注意："eslint-js" 而不是 "eslint"
    "eslint-js/no-restricted-syntax": [
      "error",
      {
        "selector": "ThrowStatement > CallExpression[callee.name=/Error$/]",
        "message": "Use `new` keyword when throwing an `Error`.",
      },
    ],
  },
}

Oxlint 还原生实现了来自 eslint-plugin-jsdoc 等插件的子集规则。对于 Oxlint 本身未实现的规则，你可以直接使用 eslint-plugin-jsdoc 包。这是推荐的模式：

{
  "jsPlugins": [
    // 为插件 "jsdoc-js" 设置别名
    { "name": "jsdoc-js", "specifier": "eslint-plugin-jsdoc" },
  ],
  "rules": {
    // 使用别名来引用插件中的规则
    "jsdoc-js/check-examples": "error",
    "jsdoc-js/require-description": "error",
    // 对 Oxlint 原生实现的规则使用普通的 "jsdoc"
    "jsdoc/require-property-name": "error",
    "jsdoc/require-property-description": "error",
  },
}

性能 ​

自从首次技术预览以来，我们已经将驱动 JS 插件的大量代码"Rust 化"，这带来了显著的性能提升。特别是依赖 tokens API 的插件（例如 ESLint Stylistic）比以前快了 5 倍。

作为一个基准测试，我们将 Node.js 的仓库从 ESLint 迁移到了 Oxlint。Node.js 是一个大型项目，利用了许多自定义 lint 规则，以及几个重量级的 ESLint 插件（总共 98 条 JS lint 规则）。

git checkout bench-eslint
npm ci
hyperfine -i --warmup 1 --runs 5 "node --run eslint"

git checkout bench-oxlint
npm ci
hyperfine -i --warmup 1 --runs 5 "node --run oxlint"

当前使用 TypeScript-ESLint 或 eslint-plugin-import 的项目可能会看到 更大 的性能提升。我们 Discord 中的一位用户 报告说，当他们从 ESLint 切换到 Oxlint 并大量使用 JS 插件时，他们公司 200 万行代码库的 lint 速度提升了 16 倍。较少使用 JS 插件的项目报告的速度提升高达 100 倍。

未来的性能改进 ​

这只是开始！

虽然带有 JS 插件的 Oxlint 已经比 ESLint 快得多，但我们管道中还有更多的优化。

Oxlint JS 插件性能的关键是一种新的、高度优化的、用于 Rust 和 JS 之间通信的底层机制，我们称之为 "raw transfer"。

Rust/JS 边界一直是支持 JS 插件的原生工具的根本问题。原生代码很快，但在 Rust 和 JS 之间来回发送数据的成本可能非常高，以至于抵消了这种增益，导致整体性能平庸。

Raw transfer 将数据在 Rust 和 JS 之间移动的成本降低到几乎为零，终于使原生代码和 JS 插件能够有效地协同工作。

Raw transfer 的第一次迭代已经在 Oxlint 的底层工作，但我们才刚刚开始利用它能做什么。随着我们继续这项工作，我们预计性能将进一步发生阶梯式变化，使 JS 插件接近原生 Rust 性能。

如果你对细节感兴趣，Oxc 核心团队成员 @overlookmotel 就这个主题 在 ViteConf 2025 做了一次演讲。

简而言之：Oxlint 已经是现存最快的 JS/TS linter。它将变得更快。

性能提示 1：使用格式化工具 ​

我们强烈建议从使用 linter 进行代码格式化转向使用 Oxfmt（或你首选的格式化工具），如果可以的话。

Oxfmt 比 Prettier 快 30 倍，并且与 ESLint Stylistic 等 linter 插件相比，也将大幅减少 lint 时间。

Oxlint 和 Oxfmt 是非常强大的组合！

性能提示 2：明智地选择插件 ​

与许多人的看法相反，编写高性能的 JavaScript 代码是完全可能的。Oxlint 速度快不仅仅是因为它是用 Rust 编写的——它也是经过精心设计，考虑了性能。

JS 插件本身的代码不在 Oxlint 的控制之下。要从整体上获得 Oxlint 的良好性能，需要你选择的 JS 插件也表现良好。

如果插件使用低效的算法或执行大量的文件系统操作，它在 ESLint 中会很慢，在 Oxlint 中也会很慢。Oxlint 可以 做的是提供一个闪电般的解析器和供插件接口的高性能 API，但它不能神奇地让缓慢的 JS 代码变快。

如果你发现 lint 速度不如你想要的快，我们将来会提供一个实用工具来诊断哪些插件/规则是你项目中的性能瓶颈。

创建自定义插件 ​

如果您的项目有特定需求，为 Oxlint 创建自定义 JS 插件很简单。

请参阅 JS 插件指南。

常见问题 ​

Oxlint 可以运行 ESLint 插件吗？ 可以。大多数插件无需修改即可工作。

Oxlint 比 ESLint 更快吗？ 是的。基准测试通常显示 4 倍到 100 倍的速度提升。

我可以逐步迁移吗？ 可以。您可以同时运行 Oxlint 和 ESLint。

致谢 ​

将 JS 插件推进到这个里程碑是许多人共同努力的结果。特别是，我们要感谢：

• @Sysix 为语言服务器集成所做的不懈努力。
• @lilnasy 构建了许多 API。

加入社区 ​

我们很乐意听取您对 Oxlint JS 插件的反馈，并很高兴看到它如何帮助改善您的开发工作流程。

联系我们：

• Discord：加入我们的 社区服务器 进行实时讨论
• GitHub：在 GitHub Discussions 上分享反馈
• Issues：向 oxc 报告 oxlint 错误。