写过 TypeScript 的人,今天才知道 ESLint 每次跑类型检查都在重复造一个 TypeScript 编译器——tsgolint v7 把这件事从根上原生化了
写过 TypeScript 的人,今天才知道 ESLint 每次跑类型检查都在重复造一个 TypeScript 编译器——tsgolint v7 把这件事从根上原生化了。
配过大型 TypeScript 项目 CI 的人都清楚:ESLint 加了 @typescript-eslint/plugin 之后,lint 时间从几秒跳到几十秒。原因不是规则太复杂,而是每条类型规则触发时,ESLint 实际上在后台重新跑了一整个 TypeScript 编译器。
这就是 tsgolint 要解决的问题。
tsgolint 是什么
tsgolint 是 Oxlint 的类型感知引擎,2026 年 9 月 11 日发布 v7 稳定版。它不走 ESLint 那种「派生子进程跑 tsc」的弯路——直接用 Go 语言写的 typescript-go(TypeScript 官方编译器 Go 移植版)做类型检查,Oxlint 用 Rust 做文件发现和语法级规则,两者通过二进制通信。
简单说:同一个 TypeScript 程序,Oxlint 给你语法级规则的速度,tsgolint 给你类型级规则的精度,但只多一次本地进程调用,没有额外的编译器冷启动。
性能数据
Oxc 官方在 GitHub benchmark 仓库里跑了四个大型代码库,结果如下:
- microsoft/vscode:ESLint+typescript-eslint 83.2 秒,tsgolint 6.96 秒,12 倍差距
- microsoft/typescript:ESLint+typescript-eslint 27.2 秒,tsgolint 1.94 秒,14 倍差距
- typeorm/typeorm:ESLint+typescript-eslint 13.2 秒,tsgolint 0.75 秒,18 倍差距
- vuejs/core:ESLint+typescript-eslint 12.3 秒,tsgolint 0.95 秒,13 倍差距
测试环境:Apple M4 Pro,12 核。ESLint 和 tsgolint 使用相同的 TypeScript 7 兼容项目配置。
tsgolint v7 覆盖了 typescript-eslint 61 条类型感知规则中的 59 条,自 alpha(43 条)以来新增了 16 条,包括 consistent-return、dot-notation、prefer-find 这些在 vscode 项目里会高频触发的规则。
为什么这次是「从根上」
过去 ESLint 社区试过别的加速方案,比如用 ESLint 自己的 worker pool 缓存类型检查结果。但根本问题没变:每次 lint 还是要先启动一个 TypeScript 语言服务进程,而这个进程跟你的 tsc --noEmit 做的类型检查几乎一模一样。
tsgolint 的思路是:既然 typescript-go 已经是一个完整的类型检查器,那就让它直接跑在 Oxlint 的类型规则里,不需要额外的进程间通信开销,也不需要 ESLint 那套插件架构做中间层。
两者用同一套 TypeScript 程序,所以 --type-aware --type-check 可以同时输出类型感知 lint 诊断和 TypeScript 编译器错误——相当于一次分析,同时给出 lint 级别和类型检查级别的反馈。
迁移成本
从 ESLint 迁移过来,两条命令:
pnpm add -D oxlint oxlint-tsgolint@7
pnpm oxlint --type-aware
已有的 ESLint 配置可以用 npx @oxlint/migrate --type-aware 翻译成 Oxlint 配置。不过有几个限制:
- 依赖 TypeScript 7.0+
- 一些 TypeScript 6 的废弃特性(如某些
tsconfig选项)不受支持 - 59/61 条类型感知规则,有 2 条尚未迁移
下一步
如果你现在跑一次 pnpm eslint . 要 10 秒以上,可以先在分支上试一下:
pnpm oxlint --type-aware --debug timings
--debug timings 会按耗时排序输出每条规则的耗时,帮你定位哪条规则最慢——这在 ESLint 里基本做不到。
tsgolint v7 的稳定发布,意味着 TypeScript 类型感知 lint 的性能瓶颈第一次有了生产级的解法。不是优化配置,不是减少规则,而是换掉底层跑类型检查的那套机制。
评论区
登录后可评论。