ESLint 最坚固的护城河，正被 Rust 和 Go 联手攻破
作为 Oxlint 背后的类型感知代码检查引擎，tsgolint 已发布稳定版 v7，将 Go 的原生速度带给长期以来由团队通过 ESLint 运行的 TypeScript 代码检查规则。
tsgolint 负责处理需要 TypeScript 语义分析的规则，这些规则可以回答某个 Promise 是否得到 await 等问题。它没有重新实现类型检查器，而是在 typescript-go 之上构建真正的 TypeScript 程序。typescript-go 是编译器的官方 Go 移植版本，并作为 TypeScript 7 发布。由 Rust 编写的 Oxlint 负责文件发现、配置和低成本的语法规则，然后将类型感知工作交给 Go 二进制程序，后者返回结构化诊断信息。该版本跟进 TypeScript v7.0.2，支持 typescript-eslint 61 条类型感知规则中的 59 条，高于去年 12 月 Alpha 版的 43 条。
只需运行两条命令即可开始使用：
pnpm add -D oxlint oxlint-tsgolint@7
pnpm oxlint --type-aware添加 --type-check 后，可以基于同一个 TypeScript 程序，在代码检查诊断信息之外同时报告编译器错误。这两个标志都可以固定写入 oxlint.config.ts 或 .oxlintrc.json 文件。该版本还增加了单条规则计时功能，可以通过 oxlint --type-aware --debug 显示计时信息，让团队看到哪些类型感知规则占用了最多运行时间。团队的基准测试显示，在搭载 Apple M4 Pro 的设备上，稳定版对 microsoft/vscode、microsoft/typescript、typeorm 和 vuejs/core 的检查速度是 ESLint 搭配 typescript-eslint 的 12 至 18 倍。
Jökull Sólberg 在该版本发布前得出结论，认为“Oxlint 正在进行正确的长期押注”。他的理由是，与 tsgo 保持一致，可以继承“TypeScript 团队未来发布的每一项优化，同时让规则范围与 typescript-eslint 保持一致”。类似观点也贯穿于一场讨论 Biome 是否也应采用 typescript-go 的 Biome 讨论中。Biome v2 不依赖编译器，而是自行推导类型；一项分析显示，其 noFloatingPromises 规则只能覆盖 typescript-eslint 所发现情况的约 75%。该分析还指出，Vite 创始人 Evan You 已公开质疑这一差距。
typescript-eslint 团队的贡献者 auvred 创建了最初的原型，但该团队仍将自己的 tsgolint 分支称为一项“没有积极开发”的实验。在 oxc 一侧，正确性仍在持续改进，用户也在提交相关报告。例如，一份报告指出，某项自动修复删除了一个实际上为 tsc 所必需的类型断言。
ESLint 用户可以运行 npx @oxlint/migrate --type-aware 来转换现有配置，具体方法参见从 ESLint 迁移指南。需要注意的是依赖要求，因为类型感知代码检查需要 TypeScript 7.0 或更高版本，不支持 baseUrl 等部分旧版 tsconfig 选项，而且使用已从 TypeScript 6 中移除的功能的项目必须先完成迁移。
从实验性的 0.x 版本直接跃升至稳定版 v7 是一次有意为之的变更，因为 tsgolint 现在会根据其嵌入的编译器确定版本：v7.0.2000 对应 TypeScript 7.0.2。目前的工作重点是完成最后几条规则、编辑器集成和 Monorepo 性能优化。
代码检查是一种静态分析步骤，用于在代码运行前标记潜在缺陷并强制执行约定。其中成本最高的一层是类型感知代码检查，它需要建立真实的程序类型模型，才能回答仅凭单个文件无法解决的问题。
Oxlint 是 oxc 中的代码检查器。oxc 是一套基于 Rust 的 JavaScript 工具，由 VoidZero 旗下团队开发。VoidZero 是 Evan You 为整合众所周知的碎片化工具链而创办的公司，而 tsgolint 则使 Oxlint 能够直接使用真正的编译器，而不必重新实现一个。它的稳定版本发布之际，整个工具链正广泛使用原生语言重写，范围从打包器和格式化工具一直延伸到 TypeScript 编译器本身。
原文链接：https://www.infoq.com/news/2026/09/tsgolint-oxlint-typescript/