Bun 1.4.3：内置类型检查器 bun check…

Bun 1.4.3 于10月10日发布。新增的 bun check 是移植自 typescript-go 的类型检查器，Bun 称它读取 tsconfig.json 并报告与 tsc 相同的错误。

给 run、test、build 加上 --check 后，存在类型错误时会阻止执行、测试或输出。检查器本身不输出 JavaScript 或 .d.ts 文件，也没有语言服务，编辑器仍使用 TypeScript。

Bun 表示，在16核 Apple silicon Mac 上它比 tsc 7.0.2 快 3 到 6.4 倍。这是供应商的测量。

针对文件的 --check 与项目检查的覆盖差异

文档给出一张对照表，把 tsc --noEmit && bun src/index.ts 这样的两步流程换成一条 bun --check src/index.ts。检查与执行之间的间隙被合并为一条命令。

不过覆盖范围不同。不带参数的 bun check 检查 tsconfig.json 中 files、include、exclude 选定的文件；而对文件使用 --check 时，只检查该文件及其静态导入。

--check 不覆盖 worker（new Worker）、名称经计算的 import()、TypeScript 文件中的 require()、代码启动的进程以及通过 preload 先加载的文件。若 tsconfig.json 包含它们，bun check 会覆盖。

若 package.json 中有 check 脚本，bun check 会执行该脚本，内置检查器需用 bun --check 选择。

入口点通过检查时，单独启动的 worker 中仍可能存在类型错误。入口检查有用，但并不能证明 worker 已被检查。

这首先是覆盖问题，其次才是速度问题。为每个源码子树、生成的类型依赖和单独启动的进程指明由哪次调用负责检查，空白就会显现。

发布说明称 bun check 通过了 TypeScript 7.0.2 一致性测试套件的全部 51,210 项测试。

同时也公开了不一致：在72个故意错误配置的开源项目中有1处，关闭 strict 的重跑中有12处，离线模糊测试中有191处。

这证明了大量兼容性工作，但不能证明对所有程序都给出相同诊断。本文没有重新运行任何检查器基准或兼容性测试。

较现实的试验是保留现有的全项目 CI 检查，只给选定的开发命令加上 --check。文档和发布说明给出的命令如下。

bun check
bun --check src/index.ts
bun test --check
bun build --check ./src/index.ts --outdir out

发布说明还给出了在同一项目上比较 tsc 与 bun check 输出的步骤。

bunx -p typescript@7.0.2 tsc --noEmit --pretty false > tsc.txt
bun check --no-pretty > bun.txt
diff tsc.txt bun.txt

下一步似乎是在可丢弃的分支中故意加入类型错误，确认命令会停止，包括单独加载的文件。这是建议的检查，而非本文获得的结果。

文档警告，不带类型检查器的旧版 Bun 遇到 "check": "bun check" 脚本时会无休止地重复执行自身。若团队尚未全部升级，文档建议把脚本命名为 typecheck。

声明文件的生成仍由 tsc 负责，编辑器也继续使用自己的 TypeScript。

--check 的价值在于让选定的执行路径更早停下，而该路径之外的覆盖仍要靠全项目检查来守住。