借助 TypeScript 7 更快地迭代
2026年6月26日由 VS Code 团队发布，@code
VS Code 和 TypeScript 几乎是一起成长的。我们很早就下定决心用 TypeScript 编写 VS Code，并且一直与 TypeScript 团队紧密合作，在 VS Code 中提供出色的内置 TypeScript 和 JavaScript 语言支持。这篇文章讲述的是这段旅程的下一步：TypeScript 7，以及我们如何通过合作采用 TypeScript 7 来加快构建速度、改善开发人员和 AI 代理的日常编码循环，并帮助 TypeScript 团队发布经过更充分测试的版本。
TypeScript 7 是用 Go 语言对 TypeScript 编译器和语言工具进行的完整移植。这意味着它的速度极快，在许多情况下甚至能快 10 倍以上。VS Code 从这些速度提升中收益匪浅，因此我们自然渴望尽早采用 TypeScript 7。
然而，我们也知道这需要时间。当我们在 2025 年夏天开始这一过程时，对于一个完全重写的项目来说，TypeScript 7 的进展实际上已经快得惊人了，但它仍然存在类型检查不一致的问题，并缺少许多我们需要的功能。即便如此，我们还是希望立即开始测试并提供反馈。在 TypeScript 7 仍在构建的同时就去采用它听起来可能有点疯狂，但事实证明，这对 VS Code 和 TypeScript 来说都是一个绝佳的决定。
渐进式迁移
VS Code 团队从不畏惧承担大型工程任务，无论是在代码库中启用严格的空值检查、添加远程开发支持，还是在数千个文件中排查并防范危险的代码模式。这些工作的一个共同主题是，我们尝试采用渐进式的方法。这意味着将庞大而复杂的问题分解为小步骤。这些步骤直接在主代码库中进行（没有分支或长期存在的分支），每完成一步通常都会带来一点改进。只要迈出足够多的小步，最终回首时你会发现，自己已经悄然攻克了那个曾经看似不可逾越的挑战。
我们希望对采用 TypeScript 7 采取同样的方法。对我们而言，这意味着将 TypeScript 7 逐步引入到工作流和代码库的不同部分，从影响较小、风险较低的区域开始，最后再过渡到 VS Code 的主要区域。渐进式工作有许多好处，其中有两点对这项工作尤为重要：
-
降低风险。采用的每一步都相对较小，因此如果出现问题，很容易找出原因并回滚。
-
早期反馈。我们希望在 TypeScript 7 开发的早期阶段就开始测试并向 TS 团队提供高质量的反馈。这意味着要尽可能多地使用 TypeScript 7，同时又不能对 VS Code 团队开发人员的生产力产生负面影响。
这种测试帮助我们发现了错误和局限性，以便他们能够优先修复。随着我们在代码库的更多部分采用 TS 7，这些区域也成了针对每个新的 TypeScript 7 每日构建版本（nightly release）的非正式回归测试。
在实践中，这种渐进式的理念在约六个月的时间里分为几个阶段逐步展开。每个阶段都进一步增加了我们对 TypeScript 7 的使用和测试，与 TypeScript 7 自身的进展保持同步，并在过程中帮助塑造了它。具体过程如下：
探索阶段（2025 年夏至初秋）
TypeScript 7 于 2025 年 3 月正式公布。到了夏天，它已经准备好进行初步测试，尽管此时它仍存在已知的 Bug 和局限性。
类型检查的进展比代码生成（emit，即生成 JavaScript 输出文件的过程）要快，因此我们早期的测试主要集中在使用 --noEmit 在我们的一些小型扩展上手动运行 @typescript/native-preview npm 包。我们随时发现问题随时报告，而且由于 native-preview 包每天都在更新，我们可以快速测试新的更改和修复。
作为 TypeScript 7 的一部分，TypeScript 团队还在构建新的语言服务器，该服务器将为 VS Code 的编辑器内 TypeScript 和 JavaScript 支持提供动力。这是通过 TypeScript 原生预览版 VS Code 扩展发布的，它用新的 TypeScript 7 语言服务器替换了 VS Code 内置的 JavaScript 和 TypeScript IntelliSense。我们与 TypeScript 团队合作，使得在两个 TypeScript 版本之间来回切换变得十分容易。这种灵活性至关重要，因为此时 TypeScript 7 仍然缺少许多基本的语言功能。我们希望让开发人员觉得，他们可以以尽可能小的精力和风险去尝试它。
我们还简化了直接从 VS Code 报告 TypeScript 7 问题的流程。简化报告意味着开发人员甚至在遇到微小烦恼时也会毫不犹豫地提交。这些报告源源不断地为 TypeScript 团队提供了现实世界的反馈。
在此阶段，大部分测试是由一小部分积极性高的 VS Code 团队成员完成的，他们对 alpha 测试感兴趣，并且愿意容忍并绕过一些烦人的问题。
TS 6 过渡桥梁（2025 年秋）
与此同时，TypeScript 团队正在思考如何简化向 TypeScript 7 的过渡，而不是让用户一次性迈出巨大的一步。既然已经是 2025 年，这种思考莫名其妙地伴随着一个令人费解的手势，其结果就是这个恰如其分地命名为 TypeScript 6.0 的版本。
TypeScript 6.0 充当了 TypeScript 5.9 与 7 之间的桥梁。因此，TypeScript 6.0 中的大部分更改都是为了帮助对齐并为采用 TypeScript 7 做准备
— https://devblogs.microsoft.com/typescript/announcing-typescript-6-0/
这样一座桥梁是必不可少的，因为 TypeScript 7 为团队提供了一个机会，去修复和现代化 TypeScript 工具中某些长期存在的痛点。例如，较旧的 TypeScript 版本默认目标为 ES5。这在 2014 年 ES6（又称 ECMAScript 2015）尚未定稿时是合情合理的，但在 2025 年看起来就极其不合时宜了。对于新开发人员来说，这也是一个陷阱（footgun），他们常常会因为忘记设置 target 而无意中生成更大、效率更低的 JavaScript 文件。同样，TypeScript 5 默认没有启用严格空值检查，因此许多用户仅仅因为不知道需要启用它而错过了这个真正具有变革意义的功能。
对于 VS Code 团队的我们而言，与直接采用完全重写的 TypeScript 7 这一宏大前景相比，切换到 TypeScript 6 只是一个风险很小的小步骤。它只需要做一些微小的代码更改。尽管如此，这小小的一步让我们更有信心确信我们的代码库处于良好状态，并且一旦 TypeScript 7 准备就绪，我们就能够毫无问题地切换过去。
TS 6 与 7 并行运行（2025 年秋）
接下来是时候认真开始使用 TypeScript 7 了。我们从风险最低的区域开始：使用 TypeScript 7 对内置扩展进行类型检查。在此阶段，我们继续运行 TypeScript 6 进行完整的类型检查和 JavaScript 生成（emit）。我们配置了持续集成（CI），要求 TypeScript 6 和 7 的构建都必须通过。通常情况下，TypeScript 6 和 7 之间的类型检查结果是一致的，但同时运行两者的确帮我们捕获了一些差异并进行了报告。
到此时，得益于 TypeScript 团队的扎实工作，TypeScript 7 中的语言服务器也取得了更大进展，因此我们将 TypeScript 7 扩展作为依赖项添加到了 VS Code 仓库中，以便我们的开发人员可以轻松切换到它。我们的目标是逐步改进编辑器支持，让开发人员能够花越来越多的时间使用 TypeScript 7。我们优先处理任何导致开发人员切换回 TypeScript 6 的问题，无论是 Bug 还是缺失的功能。
开发人员最初切换回 TypeScript 6 的最常见原因之一可能会让人有点意外：代码格式化。通常情况下，你可以忍受建议不够完美，甚至忍受 Go to Definition 表现不一致，但 TypeScript 6 和 7 之间的格式化差异会导致我们的 PR 提交前检查和持续集成格式化检查失败。这使得即使是微小的格式不一致（例如多余的空白字符）也具有了超乎寻常的优先级。随着时间的推移，这些格式化问题得到了解决，开发人员不得不切换回 TypeScript 6 的次数也越来越少。
在大多数扩展中采用 TypeScript 7（2026 年 1 月和 2 月）
到 2026 年初，TypeScript 7 已经具备了我们开始全面使用所需的一切。TypeScript 团队做出了令人惊叹的工作，使类型检查变得可靠、完成了 emit 的开发，并改进了编辑器中的语言工具。是时候开始全面切换到 TypeScript 7 了。
与往常一样，我们希望谨慎、渐进地推进，因此我们开始逐一迁移内置扩展。这些内置扩展从根本上讲与你可以使用 yo code 创建的 VS Code 扩展非常相似。在切换之前，这些扩展使用的是以下构建工具：
tsc（TypeScript 6）用于类型检查和开发构建。webpack用于生产和 Web 打包。esbuild用于快速生成代码（emit）。
作为 TypeScript 7 迁移的一部分，我们决定通过将打包工具从 webpack 切换为 esbuild 来简化构建。这简化了我们的构建工具链，并显著减少了生成打包文件所需的时间。
我们新的构建设置变得更简单了：
tsgo（TypeScript 7）用于类型检查和开发构建。esbuild用于生产和 Web 打包。
我们分小组迁移了这些扩展，以最大限度地减少任何回归问题的影响。这也让我们能够从最简单的扩展开始，在处理更复杂的扩展之前积累知识和信心。这个过程总体上很顺利，考虑到我们之前已经在使用 TypeScript 7 构建这些代码，这其实并不令人意外。
采用 TypeScript 7 作为默认版本（2026 年 2 月）
最后一步是在日常开发中切换到 TypeScript 7。到那时，TypeScript 团队的修复已经消除了我们一直在规避的阻塞问题，而且由于渐进式步骤已经完成了大部分工作，因此这次的代码更改实际上非常微小。例如，这里是相关的更改，它将我们的常规监视（watch）任务切换为使用 TypeScript 7。
我们还将 TypeScript 7 设为 VS Code 仓库编辑器中使用的默认版本。我们仍然支持作为应急手段切换回旧版本的 TypeScript，但在实践中很少需要这样做。大多数开发人员都乐于留在 TypeScript 7 上，因为它具有显著提升的性能。
数据说明一切
那么，这一切都值得吗？答案是明确而响亮的：是的。
以下是对 VS Code 主源代码进行类型检查的迁移前后对比：
# TS 6.0
tsc --noEmit -p src/tsconfig.json
36 seconds
# TS 7
tsgo --noEmit -p src/tsconfig.json
5 seconds
TypeScript 7 的速度快了七倍以上！考虑到这两项任务在做同样的工作：它们以相同的严谨度对相同的文件进行类型检查并报告相同的错误，这尤为令人印象深刻。仅仅通过从 TypeScript 6 切换到 TypeScript 7，我们的类型检查速度就提升了 7 倍。
有了 TypeScript 7，我们现在还可以在不到一秒的时间内对几乎所有的内置扩展进行类型检查。唯一的例外是我们较大的 Copilot 扩展，而它也只需 2.5 秒。
当我们查看编译和类型检查整个 VS Code（即我们的主源代码以及大约五十个内置扩展的 tsconfig 项目）时，结果会更加令人瞩目。这就是 npm run watch 命令所做的事情，这也是从事 VS Code 开发的人员通常运行的命令。
使用 TypeScript 6 时，npm run watch 大约需要 80 秒才能完成。迁移到 TypeScript 7 后，我们将这一时间缩短到了 20 秒出头：速度大约快了四倍。这意味着在每次需要重启构建时（初始监视完成后再次进行检查最多只需大约一秒钟），在日常开发和代理（agent）辅助迭代中整整节省了一分钟。
这些改进也转化为了编辑器中更好的语言工具性能。对于编辑器中的 TypeScript 语言功能，我们需要加载整个 tsconfig 项目，然后才能提供正确的错误提示以及自动导入等复杂功能。对于 VS Code 主项目，这过去需要接近一分钟的时间。现在只需大约 10 秒。这大约节省了 50 秒。由于 VS Code 开发人员经常一天多次重新加载编辑器窗口，这些节省下来的时间累积起来非常可观。再也不需要在编辑器工具加载时跑去快速喝杯咖啡了。
看到这些数字，真正让我们对改进的规模有了直观的认识。我们很容易忽视整体的影响，因为我们的渐进式方法意味着许多改进是逐渐到来的，而不是通过一个巨大的 PR 一次性实现的。早期的步骤可能只在这里节省了一秒，或者在那里节省了几百毫秒。然而，到最后，这些小小的胜利汇聚成了一个巨大的成果。看到 TypeScript 团队如何兑现他们最初的承诺，也同样令人惊叹：它依然是完整的 TypeScript，只是速度快得多。
通过协作实现更好
采用 TypeScript 7 对从事 VS Code 开发的人员来说是一次巨大的胜利，但这项工作还有一个不太显眼、可能甚至更有影响力的成果。事实证明，VS Code 庞大而复杂的代码库是发现 TypeScript 7 中的实际 Bug 并打磨其编辑器工具的极佳途径。
VS Code 团队的开发人员也毫不吝啬地就缺失的功能或任何感觉不对劲的地方提供反馈。每当开发人员遇到棘手问题并切回 TypeScript 6 时，这就是给 TypeScript 团队的一个信号，告诉他们接下来应该修复什么。其结果是一个经过更充分测试和打磨的 TypeScript 7 版本，我们知道它在 VS Code 代码库之外也能非常出色地工作。
尽管这篇文章我们主要聚焦于 VS Code 这一侧的故事，但 TypeScript 团队确实配得上几乎所有的赞誉。毕竟，是他们在构建 TypeScript 7，同时还要应对来自那些“讨厌的”VS Code 开发人员的所有反馈。我谨代表我本人以及 VS Code 团队的其他成员，向你们表示感谢！
对于该语言而言，TypeScript 7 是令人振奋的前进一步。无论你是在 VS Code 中编辑代码、在命令行中启动编译，还是让 AI 代理在项目上进行迭代，性能的提升都是显著且显而易见的。多亏了 TypeScript 团队的工作以及本文概述的测试和反馈流程，对许多代码库而言，切换到 TypeScript 7 应该是一个相对顺利的过程，并且能轻松带来收益。
最重要的是，我希望这篇文章能展示渐进式工作、尽早且频繁地测试、以及构建紧密的反馈循环以进行密切协作的价值。这些一直是 VS Code 秉持的价值观，它们在这项工作中再次为我们提供了很好的服务。我希望这个故事能激发你以不同的方式思考如何应对自己项目中的大型工程任务，并最终交付更好的代码。
编码愉快！ 💙