VS Code 迁移 TypeScript 7 实录：类型检查提速 7 倍
TypeScript 7 是 TypeScript 编译器与语言工具链的 Go 语言完整移植，很多场景快 10 倍以上。VS Code 从 2025 年夏天就开始测试并逐步采用 TypeScript 7，用约六个月的时间完成了渐进式迁移。这篇官方博客详细记录了整个过程：类型检查从 36 秒降到 5 秒、watch 构建从 80 秒降到 20 秒、编辑器语言工具加载从近一分钟降到约 10 秒。
为什么值得迁移
VS Code 和 TypeScript 几乎是共同成长的：VS Code 很早就选择用 TypeScript 编写，并一直与 TypeScript 团队紧密协作，提供内置的 TypeScript/JavaScript 语言支持。TypeScript 7 是完整的 Go 移植，这意味着快——而且这种提速对 VS Code 和开发者都直接可感。
但团队也清楚这需要时间。2025 年夏开始时，TypeScript 7 作为一次完整重写已经进展惊人，但仍存在类型检查不一致，也缺少很多需要的特性。即便如此，尽早测试和反馈是值得的。
渐进式迁移的六个阶段
VS Code 团队的习惯是把大型工程拆成小步骤，在主代码库中推进（不分叉、不搞长期分支），每一步落地都带来一点小改进。迁移 TypeScript 7 同样如此，从低影响、低风险区域开始，逐步扩展到 VS Code 主体。
探索阶段（2025 夏至初秋）：TypeScript 7 于 2025 年 3 月公开宣布，夏季可做初步测试。当时类型检查比 emit（生成 JavaScript 输出文件）更成熟，早期测试主要是在小型扩展上手动运行 @typescript/native-preview 包配合 --noEmit。TypeScript 团队同步构建新语言服务器，通过 TypeScript native preview 扩展替换 VS Code 内置的 JavaScript/TypeScript IntelliSense。团队与 TypeScript 团队合作，让两个版本之间切换很容易，并在 VS Code 里直接报 TypeScript 7 的问题。
TS 6 桥接（2025 秋）：TypeScript 团队为减少迁移跳跃感发布了 TypeScript 6.0，作为 5.9 与 7 之间的桥。它顺带修正了长期存在的工具性问题：旧版本默认 target ES5、TypeScript 5 不默认开启严格空检查。对 VS Code 而言，切到 TS 6 是小而低风险的一步。
TS 6 与 7 并行（2025 秋）：开始认真使用 TypeScript 7 检查内置扩展，CI 同时要求 6 和 7 的构建通过。此阶段最常见的切回原因是代码格式化——TS 6 与 7 的格式化差异会让 PR 预提交检查和 CI 格式化检查失败，小小空白差异获得超乎寻常的优先级。
大多数扩展迁移（2026 年 1-2 月）：TypeScript 7 的类型检查可信、emit 完成、编辑工具成熟。团队逐个迁移内置扩展，并把打包工具从 webpack 简化为 esbuild。新构建配置变成：tsgo（TS 7）做类型检查和开发构建，esbuild 做生产与 Web 打包。
默认启用（2026 年 2 月）：最后一跳实际很简单，因为渐进步骤已完成了大部分工作。watch 任务切换到 TypeScript 7，编辑器也默认使用新版本，仍保留切回旧版本的逃生通道，但实践中很少用到。
实测数据
- 主源码类型检查：TS 6.0 的 tsc --noEmit 36 秒 → TS 7 的 tsgo 5 秒，快 7 倍以上，做的是同样的检查、报告同样的错误；
- 几乎所有内置扩展的类型检查现在 1 秒内完成，最大的 Copilot 扩展也只要 2.5 秒；
- 编译并检查全部 VS Code（主源码加约五十个内置扩展 tsconfig 项目）的 npm run watch：80 秒 → 20 秒左右，快约 4 倍，每次重启构建省一分钟；
- 编辑器语言工具需要先加载整个 tsconfig 项目：从接近一分钟降到约 10 秒，每次重载窗口省约 50 秒。
这套增量迁移的收益不止于 VS Code：每一步都在为主干的每个 TypeScript 7 nightly 版本提供非正式回归测试，帮助 TypeScript 团队发布了经过更多真实场景验证的版本。对要迁移到 TypeScript 7 的团队，这篇文章本身就是一份可复制的路线图——从小处开始、双版本并行、把格式化差异当信号、最后一步自然发生。
来源：Iterating faster with TypeScript 7 - Visual Studio Code Blog