21CTO导读：微软基于 Go 语言构建的 TypeScript 7 原生版本，正式版本发布了。

概述

TypeScript 7.0 于当地时间7月8号发布，带来了该语言历史上最彻底与重大的架构变革。

它使用 Go 语言完全重写了编译器，包括类型检查器、代码生成器、语言服务器。原生移植版本在实际代码库中实现了 8-12 倍的构建速度提升，某些项目甚至获得了更为显著的性能提升。

微软的TypeScript产品经理 Dan Rosenwasser 宣布了此项更新。

构建性能用数据说话

没错，数据足以说明一切。

VSCode 的代码库（一个庞大的 TypeScript 项目）构建时间从 125.7 秒缩短至 10.6 秒，提升了 11.9 倍。Sentry 项目的构建时间也从139.8 秒降至 15.7 秒。在所有测试的代码库中，内存使用量均降低了 6% 至 26%。

但原始构建数据只能说明部分问题。编辑器体验的改进对日常开发的影响可能更为显著。在 VSCode 中打开错误所需的时间从 17.5 秒缩短到不到 1.3 秒——提升了 13 倍，从根本上改变了开发者与大型 TypeScript 项目交互的方式。

微软将TypeScript 6.0与TypeScript 7.0放在不同的大型开源项目库上运行，速度更有鲜明的对比。

Slack的研发工程师表示，TypeScript 7将他们的合并队列时间缩短了40%，并将持续集成（CI）类型检查时间从大约7.5分钟缩短到1.25分钟。此前，由于语言服务器加载时间过长，在编辑器中进行本地开发几乎无法使用；而TypeScript 7只需几秒钟即可加载相同的代码库，使本地类型检查再次成为可能。

微软新闻服务团队报告称，每月在CI构建时间上节省了400小时。Canva开发人员表示，从编辑器启动到出现第一个错误的时间从大约58秒缩短到大约4.8秒。

为什么要用Go，而不是Rust？

Rust 其实是当时重写最热门的猜测。但TypeScript团队最终选择了 Go，原因其实很实际：它能完美地移植到现有编译器上。这套代码大量使用图结构，有垃圾回收机制，并且包含许多循环数据结构，因此忠实移植比从头重写更可行。

TypeScript 开发负责人 Ryan Cavanaugh 直言不讳的将技术原理指了出来：Rust 的所有权模型禁止循环数据结构，除非采取复杂的变通方法，而 TypeScript 的抽象语法树 (AST) 中充斥着这类结构。如果使用 Rust 移植，则需要重新设计编译器数据模型的大部分内容——这将是一项耗时数年且无法保证兼容性的工作。

“移植而非重写”的决策比语言选择更重要。由于结构得以保留，语义也得以保留。在 TypeScript 6.0 下无论是否stableTypeOrdering启用任何ignoreDeprecations标志都能顺利编译的代码，在 7.0 下也应该能够完全编译。你得到的是更快的引擎，而不是一套不同的规则。

一位HN上的评论者也总结了其中原因：“Go 语言很棒，因为它编写代码速度很快。只需查看代码，就能轻松地用 Go 语言 1:1 复现 TypeScript。而 Rust 的开发则要花费更长的时间。Rust 的速度可能比 Go 快 20%，但从 TypeScript 到 Go 的整体速度提升足以带来巨大的差异。”

TypeScript 团队明确想要的是翻译，而不是重写。他们的目标是完全兼容所有 bug，而 Go 的垃圾回收机制和更简单的内存模型使得这一目标比 Rust 的借用检查器更容易实现，因为 Rust 的借用检查器对于存在大量循环结构的编译器来说是不可接受的。

此移植版本首先在生产环境中进行了大规模验证。

在达到目前的阶段之前，它已在彭博社、Figma、谷歌、Slack、Notion 和 Vercel 等公司的数百万行代码库上运行了一年多时间。

是否升级到 TypeScript 7 

TypeScript的编译器，在6.0之前使用是TypeScript本身编写，运行在JavaScript环境中，维护方便，生态也非常成熟，但无法利用多核CPU。等由Go实现后，直接获得了原生代码性能、共享内存和多线程等能力。

升级决策几乎完全取决于你的项目使用了哪些框架和工具。

如果项目直接构建 TypeScript，并且不依赖于框架特定的模板类型检查或与 TypeScript 编译器的编程 API 的深度集成，那么 TypeScript 7.0 是一个稳定且可用于生产环境的升级版本。安装命令与之前的任何主要版本相同：


npm install -D typescript@7

然后，再运行：

npx tsc

命令没有任何变化。

Vue相关生态暂不可用，需要等待

但是，使用 Vue、Svelte、Astro 或 MDX 构建应用的研发团队目前应继续使用 TypeScript 6.0。

问题出在架构上。像 Volar（Vue、MDX 和 Astro 都使用）这样的框架模板类型检查器会将 TypeScript 编译器直接嵌入到它们自己的语言服务中，以检查应用程序中位于.ts文件之外的部分——组件模板、样式绑定和插槽类型。它们通过将 TypeScript 作为库导入并调用其编程 API 来实现这一点。TypeScript 7.0 尚未发布稳定的 API 版本；Go 实现的接口仍在不断变化中。

为了让需要同时运行两个版本的项目能够并行运行这两个版本，微软发布了兼容包：


@typescript/typescript6

这个包提供 TypeScript 6 API，以及独立的 tsc6 命令。

项目可以同时安装两个版本：

{  "devDependencies": {    "@typescript/native": "npm:typescript@^7.0.2",    "typescript": "npm:@typescript/typescript6@^6.0.2"  }}

这样通过对等依赖项导入的工具可以继续使用 TypeScript 6.0，同时tsc构建指向 TypeScript 7。

编辑器支持、监视模式和新的并行标志

VS Code：目前市场上已有专门的 TypeScript 7 扩展程序，预计未来几周内 VS Code 本身也将全面支持 TypeScript 7。安装该扩展程序后，即可通过命令面板启用或禁用 TypeScript 7 语言服务器。

Visual Studio：最新版本的 IDE 会根据工作区检测结果自动启用 TypeScript 7。无需任何操作。

其他编辑器： TypeScript 7 的语言服务器基于语言服务器协议 (LSP) 构建，LSP 是一种 JSON-RPC 标准，任何现代编辑器都支持该标准，而不是之前的自定义 TypeScript 服务器协议。任何兼容 LSP 的编辑器都会自动获得多线程方面的改进。

监视模式： TypeScript 7 提供了一个完全重构的--watch监视模式。之前的实现方式使用周期性轮询来检测文件更改，这在具有大型node_modules树状结构的项目中计算量非常大。

TypeScript 7 将 Parcel 的文件监视器从 C++ 移植到符合 Go 语言习惯的 Go 语言，通过了 Parcel 原有的测试套件，并且避免了在 TypeScript 的构建依赖链中添加 C++ 工具链。

并行标志（7.0 新增）：此--checkers标志设置类型检查器工作线程的数量（默认值：4）。增加此值可以加快多核机器上大型代码库的运行速度，但会增加内存使用量。此--builders标志控制并行项目参考构建--build。请谨慎组合使用这些标志：--checkers 4 --builders 4允许最多 16 个并发类型检查器，微软认为这可能过高。此--singleThreaded标志禁用所有并行，适用于调试或资源受限的 CI 运行器。

结语：迈向 TypeScript 7.1，稳定 API 和生态系统完善

微软明确表示7.0并非 Go 迁移的最终状态。

该团队已将 TypeScript 7.1 描述为弥合生态系统剩余差距的版本——主要是稳定的程序化 API，它将使 Volar 和框架模板类型检查器能够采用原生编译器。

预计 7.1 的发布时间与之前的版本类似：三到四个月，也就是大约在 2026 年 10 月左右发布。

伴随着 7.0 版本的正式发布，TypeScript 团队表示将回归新功能开发、人体工程学改进以及在原生运行时中实现的进一步性能优化。

作者：洛逸