TypeScript 7

# 公告 TypeScript 7.0 - TypeScript 原文链接：https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/ 今天，我们自豪地宣布 TypeScript 7 正式可用——这是一个用 Go 语言编写、速度提升 10 倍的原生移植版本！自诞生之初，TypeScript 就承诺要让 JavaScript 随规模扩展。通过为 JavaScript 世界带来强类型检查与丰富的工具链，TypeScript 使得构建跨平台的高质量复杂应用成为可能。去年，我们团队公布了 TypeScript 的下一步发展（https://devblogs.microsoft.com/typescript/typescript-native-port/）：让整个工具集的每个环节都提速一个数量级。这项任务是用 Go 语言对 TypeScript 进行原生移植，以充分利用现代硬件的性能。我们尽可能忠实地完成移植，在编写新代码的同时保持原始代码库的结构和逻辑，确保两个编译器之间的结果一致且兼容。关键区别在于，通过这个新代码库，TypeScript 7 带来了原生代码速度、共享内存多线程以及一系列新的优化，通常能在完整构建中实现 8 到 12 倍的加速。与其他版本一样，TypeScript 7 可通过 npm 获取：`npm install -D typescript`。这会将新的 `tsc` 可执行文件安装到你的工作空间中（你可以通过 `npx tsc` 运行它）。当然，TypeScript 体验的很大一部分也体现在编辑器支持上。你最喜欢的代码编辑器应当能够轻松支持 TypeScript 7，因为它提供了对语言服务器协议（LSP）的新支持，以及新的速度和多线程改进。无论你使用的是 VS Code、Visual Studio、WebStorm 还是其他现代编辑器，TypeScript 7 都能良好运行。只需查看你编辑器的文档——例如，VS Code 有一个专门用于 TypeScript 7 的扩展（https://marketplace.visualstudio.com/items?itemName=TypeScriptTeam.native-preview），你可以立即使用，而 Visual Studio 会根据你的工作空间自动启用 TypeScript 7。 ## 更快的 TypeScript 意味着什么？ 一个更快的 TypeScript 在纸面上听起来很棒，但在实践中意味着什么？或许可以从 TypeScript 在开发各阶段出现的位置来思考。典型的一天开发可能包括：打开编辑器、打开一个 TypeScript 文件、在整个项目中运行 *查找所有引用* 操作。然后当你开始编辑时，可能需要自动补全弹出，并且在编辑过程中实时看到红色波浪线。当你（以及最近可能还有 AI 代理）准备好构建项目时，你会运行 `tsc`，检查输出中的错误，然后以某种方式运行生成的代码。一个更快的 TypeScript 意味着上述每个环节都得到精简。等待编辑器完全加载项目将感觉瞬间完成。*查找所有引用*、自动补全和诊断的延迟将比以往更快。当你运行 `tsc`（可能是在 `--watch` 模式下）时，你将能够收紧反馈循环，比以往迭代更快。你可以在真实世界项目中看到这一点。事实上，你可以自己尝试在一些开源项目上进行对比。以下是在一些相当大的开源代码库上运行 TypeScript 6 和 TypeScript 7 的构建时间。 | 代码库 | TypeScript 6 | TypeScript 7 | 加速倍数 | | ----------- | ------------ | ------------ | -------- | | vscode | 125.7s | 10.6s | 11.9x | | sentry | 139.8s | 15.7s | 8.9x | | bluesky | 24.3s | 2.8s | 8.7x | | playwright | 12.8s | 1.47s | 8.7x | | tldraw | 11.2s | 1.46s | 7.7x | 上表描述了 TypeScript 6 和 TypeScript 7 之间各项目的编译时间，加速比从 7.7 倍到 11.9 倍不等。 TypeScript 7 在构建过程中通常还能以 *更少* 的总内存占用实现更好的表现。 | 代码库 | TypeScript 6 | TypeScript 7 | 内存变化 | | ----------- | ------------ | ------------ | -------- | | vscode | 5.2GB | 4.2GB | -18% | | sentry | 4.9GB | 4.6GB | -6% | | bluesky | 1.8GB | 1.3GB | -26% | | playwright | 1.0GB | 0.9GB | -11% | | tldraw | 0.6GB | 0.5GB | -15% | 上表描述了 TypeScript 6 和 TypeScript 7 之间内存减少的差异，范围从 -6% 到 -26%。 当然，体验不止于完整构建。在同一台机器上，在 VS Code 代码库中打开一个包含错误的文件，以前从打开编辑器到看到第一个错误大约需要 17.5 秒。而使用 TypeScript 7，这一时间不到 1.3 秒——快了 13 倍以上。 ## 经过实战检验，随时可用于生产 TypeScript 项目包含数万个测试，这些测试历时十余年构建，并在我们的 `main` 分支上的每次提交中运行。它们确保了每个版本的稳定性和可靠性。但 TypeScript 7 并非普通版本。除了我们的测试套件外，我们还利用了许多不同的资源来确保 TypeScript 7 在生产环境中坚固可靠。在过去一年中，我们与许多内部和外部的团队合作，在真实世界的代码库上测试了 TypeScript 7。结果非常积极，许多公司报告说 TypeScript 7 稳定、快速且易于采用。例如，VS Code 团队最近分享了他们使用 TypeScript 7 预览版本（https://code.visualstudio.com/blogs/2026/06/26/iterating-faster-with-ts-7）来加快开发周期的经验。我们还与微软的 Loop、Office、PowerBI、Teams 和 Xbox 等团队合作，确保 TypeScript 能够应对最大的代码库。同样，Bloomberg、Canva、Figma、Google、Lattice、Linear、Miro、Notion、Sentry、Slack、Vanta、Vercel、VoidZero 等公司也与我们一起在其代码库上测试了 TypeScript 7，并提供了反馈以使其更好。 此外，我们重建了大部分更广泛的测试基础设施，使其运行在 TypeScript 7 上。TypeScript 6 及更早版本在 GitHub 上对 TypeScript 和 JavaScript 项目进行了自动化和按需测试，以检测编译器和语言服务中的回归问题。同样的测试现已回归，并针对 TypeScript 7 运行，在真实代码库中发现问题的同时，我们也能找出核心测试套件中的漏洞，从而提供更好的体验。明确的反馈、自动化的崩溃报告以及积极的测试相结合，在质量上带来了可衡量的提升。事实上，我们的数据洞察显示，与 TypeScript 6.0 相比，TypeScript 7.0 的新语言服务器将语言服务器命令的失败次数减少了超过 80%，服务器崩溃次数减少了超过 60%。 我们还从大规模团队中听到了一些令人难以置信的反馈： - Slack 的工程师告诉我们，TypeScript 7 消除了他们合并队列 40% 的时间，并将 CI 中的类型检查时间从大约 7.5 分钟缩短到 1.25 分钟（https://bsky.app/profile/slack.engineering/post/3lry3ml3qok2f）。此前，由于语言服务器加载时间过长，本地编辑器开发几乎“无法使用”，工程师们通常让 CI 进行完整的类型检查。TypeScript 7 能够在几秒钟内加载相同的代码库，使得本地类型检查再次可行。 - Vanta 的构建得到了显著改善，在其最大的一个项目上实现了高达 9 倍的加速（https://bsky.app/profile/chriskrycho.com/post/3melxwy2lkycq）。 - 同样，微软的新闻服务团队告诉我们，采用 TypeScript 7 每月为他们节省了 400 小时的 CI 构建等待时间。 - 去年，从事 PowerBI 工作的工程师将编辑器中的 TypeScript 7 描述为处理其代码库的“救星”。在 TypeScript 7 甚至还没有在 VS Code 中支持重命名功能之前，他们就已经将其作为默认体验。 - 从事 Loop 单体仓库的开发者也非常兴奋。以前在如此规模下，编辑器体验被描述为无法使用，而 TypeScript 7 的体验“令人惊叹”。 - Canva 的开发者告诉我们，TypeScript 7 的语言服务显示出惊人的加速，从看到第一个错误大约需要 58 秒缩短到约 4.8 秒。 ## 与 TypeScript 6.0 并行运行 虽然 TypeScript 7.0 已经推出，但它并未附带 API。我们预计 TypeScript 7.1 将附带一个新的（且不同的）API，但在那之前，我们已将确保 TypeScript 能够与 TypeScript 6.0 并行运行作为优先事项，以便那些仍然需要以编程方式访问编译器（例如 typescript-eslint）的工具能够正常工作。作为 6.0/7.0 过渡过程的一部分，我们发布了一个新的兼容包 `@typescript/typescript6`。该包提供了一个名为 `tsc6` 的可执行文件，因此如果需要，你可以安装 TypeScript 7.0（其自带 `tsc` 二进制文件）而不产生命名冲突。新的包还重新导出了 TypeScript 6.0 API，因此你可以将 `tsc` 用于 TypeScript 7，而其他工具可以继续依赖 6.0。由于某些工具（如 typescript-eslint）期望通过 peer 依赖直接导入 `typescript`，我们建议通过 npm 别名来实现这一点。你应该能够运行以下命令： ``` npm install -D typescript@npm:@typescript/typescript6 ``` 或者修改你的 `package.json` 如下： ```json { "devDependencies": { "typescript": "npm:@typescript/typescript6@^6.0.2" } } ``` 请注意，这样做之后你只会得到一个 `tsc6` 可执行文件。要获得 TypeScript 7.0 的 `tsc`，你可以为 TypeScript 7 添加另一个别名，这样 `npx tsc` 就会使用 7.0： ```json { "devDependencies": { "@typescript/native": "npm:typescript@^7.0.2", "typescript": "npm:@typescript/typescript6@^6.0.2" } } ``` ### 每日构建和 `@typescript/native-preview` 到目前为止，大多数开发者通过 `@typescript/native-preview` 包安装 TypeScript 7。该包提供了新代码库的每日构建，并且每周下载量超过 850 万次，深受社区喜爱！不过，展望未来，每日构建将很快在标准 `typescript` 包下以 `next` 标签恢复。你可以通过以下命令安装： ``` npm install -D typescript@next ``` ## 自定义扩展：并行化与控制 TypeScript 7.0 现在可以并行执行许多步骤，包括解析、类型检查和生成代码。其中一些步骤（如解析和代码生成）主要可以在文件之间独立完成。因此，并行化在较大的代码库中能够自动良好扩展，且开销相对较小。但 TypeScript 构建中的并非每个步骤都容易并行化。TypeScript 7 引入了实验性的 `--checkers` 和 `--builders` 标志，用于微调不那么简单的步骤（如类型检查和项目引用构建）的并行化行为。它还引入了 `--singleThreaded` 标志来完全禁用并行化，这对于调试或在资源受限环境中运行非常有用。 ### 类型检查器并行化 其他步骤（如类型检查）在文件之间有更复杂的依赖关系。大多数文件最终依赖于其依赖项和全局作用域中的相同类型信息，因此完全独立地运行类型检查器将是浪费的——无论是在计算还是内存方面。另一方面，类型检查有时依赖于程序中信息的相对顺序，因此从头开始类型检查必须始终以相同的顺序检查相同的文件，以确保结果相同。为了在避免这些陷阱的同时实现并行化，TypeScript 7.0 创建了固定数量的类型检查器工作线程，每个工作线程拥有自己的世界视图。这些类型检查器工作线程可能会重复一些公共工作，但给定相同的输入文件，它们将始终以相同的方式划分这些文件并产生相同的结果。默认的类型检查器工作线程数量为 4，但可以通过新的 `--checkers` 标志进行配置。你可能会发现，在更大的代码库中，当机器具有更多 CPU 核心时，增加此数量可以进一步加快构建速度，但通常会增加内存使用量。例如，在上面的表格中，我们使用默认的 `--checkers 4` 运行了 TypeScript 7。以下是同一台机器上使用 `--checkers 8` 的结果： | 代码库 | TypeScript 6 | TypeScript 7 (--checkers 8) | 加速倍数 | | ----------- | ------------ | --------------------------- | -------- | | vscode | 125.7s | 7.51s | 16.7x | | sentry | 139.8s | 12.08s | 11.6x | | bluesky | 24.3s | 2.01s | 12.1x | | playwright | 12.8s | 1.16s | 11x | | tldraw | 11.2s | 1.06s | 10.6x | 如你所见，这些代码库通过分配更多核心获得了更好的加速效果，但结果会因项目和底层机器而异。另一方面，在 CPU 核心较少且内存较小的机器上（例如 CI 运行器），你可能希望减少此数量以避免不必要或附带的开销。你可以将值指定为低至 `--checkers 1`，从而有效地使类型检查变为单线程并消除重复工作。在极少数情况下，改变 `--checkers` 的数量可能会暴露出顺序相关的结果。在构建环境中指定固定数量的检查器有助于确保每个人获得相同的结果，但这由你的团队自行决定。 ### 项目引用构建器并行化 TypeScript 7.0 可以在项目内部并行化构建，现在还可以同时构建多个项目。这种行为可以通过新的 `--builders` 标志进行配置，该标志控制在使用 `--build` 运行时可以同时运行的并行项目引用构建器的数量。这对于具有多个项目的单体仓库尤其有帮助。与 `--checkers` 类似，增加构建器的数量可以加快构建速度，但可能会增加内存使用量。它还与 `--checkers` 具有乘数效应，因此为你的机器和代码库找到正确的平衡非常重要。例如，使用 `--checkers 4 --builders 4` 构建时，最多允许 16 个类型检查器同时运行，这可能过多。与 `--checkers` 不同，改变构建器的数量不应产生不同的结果；然而，构建项目引用从根本上受限于项目的依赖关系图（除非代码库利用 `--isolatedDeclarations` 和单独的语法声明文件生成进行类型检查）。 ### 单线程模式 在某些情况下，强制编译器全程单线程操作可能会有所帮助。这对于调试、与 TypeScript 6 和 7 进行性能比较、在外部协调并行构建或在资源极其有限的环境中运行时可能很有用。要启用单线程模式，可以使用新的 `--singleThreaded` 标志。这不仅会将类型检查器工作线程的数量限制为 1，还会确保解析和生成代码在单个线程中完成。 ## 改进的 `--watch` 模式 TypeScript 7 附带了一个完全重建的 `--watch` 模式。`--watch` 现在由基于 Parcel 打包器的文件监视器（https://github.com/parcel-bundler/watcher）的新基础架构驱动，提供了高效且稳定的跨平台文件监视能力。当我们团队着手移植文件监视逻辑时，我们在 Go 语言中遇到了跨平台文件监视的一些挑战。标准库没有提供内置的文件监视 API，而我们探索的现有第三方库在稳定性、性能、跨平台支持或构建工具集成方面存在各种问题。我们能够构建基于轮询定期检查文件更改的解决方案，这大致上在所有操作系统上都能工作；然而，它在计算上非常昂贵，尤其是在具有许多 `node_modules` 依赖关系的大型项目中。即使采用了动态调度策略，我们发现纯轮询解决方案对于一般用途来说负担过重。多年来，Visual Studio Code 一直依赖 `@parcel/watcher`（https://www.npmjs.com/package/@parcel/watcher），而最近 TypeScript 在 VS Code 中间接依赖了它的文件监视能力。虽然它看起来很有希望，但 Parcel 监视器的一个问题是它是用 C++ 编写的，因此需要完整的 C++ 工具链。