TypeScript 7.0 RC 正式发布：基于Go语言重写的全新编译器

# TypeScript 7.0 RC 正式发布：基于Go语言重写的全新编译器

**作者：吉祥法师**

## 一、核心概念

TypeScript 7.0 RC 是 TypeScript 语言发展历程中的一个里程碑式版本。该版本最核心的变化在于，TypeScript 团队将原有的 TypeScript 编译器从 TypeScript 语言本身（自举编译为 JavaScript）完整地移植到了 Go 语言上。这一底层架构的彻底重构，并非从零开始重写逻辑，而是对原有实现进行了周密、系统性的代码迁移。通过利用 Go 语言的本地代码执行速度和共享内存并行处理能力，TypeScript 7.0 在性能上实现了质的飞跃，其编译和类型检查速度通常比 TypeScript 6.0 快约 10 倍。

此次重构的核心指导思想是“架构对等”，即新的 Go 代码库在类型检查逻辑上与原 TypeScript 6.0 的实现结构完全一致。这意味着，开发者所依赖的 TypeScript 类型系统的语义和行为将得到完整的保留和继承。TypeScript 7.0 已经通过了团队在过去十年间积累的庞大测试套件的严格验证，并且已在微软内部及外部（如 Bloomberg、Canva、Figma、Google 等）的多个数百万行级代码库中投入生产使用，其稳定性和兼容性已经过充分验证，准备好了在开发者的日常工作流和 CI 管线中接受考验。

## 二、逻辑结构

本文的结构旨在全面、系统地介绍 TypeScript 7.0 RC 的关键特性、使用方法、架构变化以及对开发者的影响。文章从最直观的“获取与安装”开始，指导用户如何快速上手体验。随后，文章深入探讨了版本过渡的兼容性策略，特别是如何与 TypeScript 6.0 并行运行。接着，文章详细阐述了性能提升的基石——全新的并行化架构，包括类型检查器并行、项目引用构建并行以及单线程模式等。此外，文章还重点介绍了重建的 `--watch` 模式、对 Unicode 码点的正确处理、JavaScript 支持的新行为与差异，以及编辑器的体验改进。最后，文章给出了从 Beta 到 RC 的功能完善情况，并展望了 7.0 正式版的发布路线图，鼓励社区积极参与测试并提供反馈。

## 三、主要论点与论据

### 1. 性能革命：Go 语言带来的 10 倍加速

**论点：** TypeScript 7.0 通过使用 Go 语言重写编译器，实现了显著的性能提升，通常比上一代快 10 倍。

**论据：**

-   **底层技术优势：** Go 语言作为一种编译型、静态类型的语言，其编译产物直接运行在机器码层面，相比运行在 JavaScript 虚拟机上的编译器，具有天然的执行效率优势。更重要的是，Go 语言对并发编程提供了强大的原生支持，特别是其轻量级的 Goroutine 和用于同步的 Channel，使得编译器模块可以轻松地利用现代多核 CPU 的并行计算能力，而无需像 JavaScript 那样受限于事件循环和单线程模型的各种复杂变通方案。

-   **具体并行化策略：**
    -   **解析（Parsing）与代码生成（Emitting）的并行：** 对于一个多文件项目，解析一个源文件和生成其对应的 JavaScript 代码，在很大程度上可以独立进行，不依赖于其他文件。TypeScript 7.0 将这类“数据并行”的任务自动分配给多个工作协程，使得大规模代码库的初始构建和增量编译速度大幅提升，且并行化的开销相对较低。
    -   **类型检查（Type-Checking）的并行：** 这是最关键也最具挑战性的部分。传统上，类型检查依赖全局类型信息和文件间的依赖关系，是一个强顺序的过程。TypeScript 7.0 通过创建固定数量（默认 4 个，可通过 `--checkers` 标志配置）的类型检查器工作器来解决此问题。每个工作器拥有独立的“世界观”，接收相同的输入文件列表，并按完全相同的顺序划分文件，从而保证检查结果的确定性和一致性。虽然不同工作器之间可能重复了部分公共类型信息的计算（如 `node_modules` 中的类型），但总体而言，将检查任务分散到多个 CPU 核心上，显著提升了项目整体的检查吞吐量。

-   **实际验证效果：** 多家大型科技公司（如 Bloomberg、Figma、Google 等）在数月前就开始在它们数百万行级别的真实代码库上测试 TypeScript 7.0 的预览版。反馈报告显示，这些团队普遍观察到了与官方测试一致的性能提升，大部分构建时间被显著缩短，编辑体验也因此变得更加轻量和流畅。

### 2. 平滑过渡：与 TypeScript 6.0 的并行运行方案

**论点：** TypeScript 7.0 提供了完善的并行运行方案，确保从 6.0 到 7.0 的过渡平稳可控，不干扰现有的工具链和工作流。

**论据：**

-   **程序化 API 的过渡期：** 7.0 RC 版本虽然接近生产就绪，但其稳定的程序化 API（供其他工具如 `typescript-eslint`、Webpack loader 等调用的 API）预计要到几个月后的 7.1 版本才会发布。因此，立即将所有工具都迁移到 7.0 是不现实的。

-   **`@typescript/typescript6` 兼容包：** 为应对这一过渡期，官方专门发布了一个名为 `@typescript/typescript6` 的全新兼容包。该包的核心功能是：
    -   **提供 `tsc6` 可执行文件：** 安装此包后，开发者可以同时拥有 TypeScript 7.0 的 `tsc` 命令和 TypeScript 6.0 的 `tsc6` 命令，从根本上解决了在命令行中执行哪个 `tsc` 的混乱问题。
    -   **重新导出 TypeScript 6.0 的 API：** 该包完整且未经修改地重新导出了 TypeScript 6.0 的程序化 API。任何依赖于 `import ... from 'typescript'` 的工具，在正确配置后，仍然可以稳定地访问到 6.0 版本的 API。

-   **npm 别名解决方案：** 文章推荐使用 npm 别名（`npm aliases`）来实现上述并行运行。开发者只需修改 `package.json` 即可：
    ```json
    {
        "devDependencies": {
            // 将 'typescript' 包别名到 '@typescript/typescript6'，确保依赖该包的旧工具能正常工作
            "typescript": "npm:@typescript/typescript6@^6.0.0",
            // 为 TypeScript 7.0 创建一个新别名，例如 'typescript-7'
            "typescript-7": "npm:typescript@rc"
        }
    }
    ```
    这样配置后，`npx tsc` 指向的是 7.0，而 `eslint` 等工具通过 `import 'typescript'` 获取的是 6.0 的 API，从而实现并行运行。

### 3. 智能并行：可配置的检查器与构建器

**论点：** TypeScript 7.0 提供了精细的并行化控制，允许用户根据自身硬件和项目特点，调整并行度以获得最佳性能。

**论据：**

-   **`--checkers` 标志：** 控制类型检查并行工作器的数量。默认值为 4。
    -   **适用场景：** 在拥有更多 CPU 核心的机器（如高端开发机）上，适当增加 `--checkers` 数量（例如 8 或 16）可以进一步加速大型项目的构建，但会以增加内存使用为代价。在 CPU 核心较少、内存受限的环境（如小型 CI 运行器）中，减少此数值（例如 2 或 1）可以避免不必要的资源竞争和上下文切换开销。
    -   **注意事项：** 在极少数情况下，不同数量的检查器可能会暴露一些依赖于文件处理顺序的隐蔽问题。开发者可以在团队内的所有构建环境（本地开发、CI）中指定一个固定的 `--checkers` 数量，以确保结果的一致性和可复现性。

-   **`--builders` 标志：** 控制项目引用（Project Reference）构建的并行度。对于大型 monorepo 项目尤为有用。
    -   **并行构建项目：** 当使用 `--build` 模式构建多个项目时，此标志决定了同时可以处理多少个项目的依赖解析和构建任务。
    -   **与 `--checkers` 的乘法效应：** `--checkers` 和 `--builders` 的效果是叠加的。例如，`--checkers 4 --builders 4` 意味着同时最多可能有 `4 * 4 = 16` 个类型检查工作器在运行。这需要开发者根据自身机器的内存和 CPU 资源找到一个合理的平衡点，避免因过度并行而导致系统资源耗尽。`

-   **`--singleThreaded` 标志：** 作为一个强制性的“降级”开关，此标志可以强制编译器在所有环节（解析、类型检查、代码生成）使用单线程运行。这对于调试、在资源极度受限的环境中运行，或与外部并行构建系统（如 Bazel、Nx）协调工作非常有用。

### 4. 重建的 `--watch` 模式：基于 Parcel 的高效文件监听

**论点：** TypeScript 7.0 彻底重建了 `--watch` 模式，采用从 Parcel 打包器移植的、经过优化的文件监听器，显著提升了跨平台的稳定性和资源效率。

**论据：**

-   **原有方案的瓶颈：** TypeScript 团队在将文件监听逻辑移植到 Go 时，遇到了挑战。Go 标准库没有提供跨平台的内置文件监听 API，而探索过的第三方库在稳定性、性能或跨平台支持上存在缺陷。为了兼容所有操作系统，最初尝试了基于轮询（polling）的方案，但它计算成本极高，尤其在监控大型 `node_modules` 目录时，即使采用了动态调度策略，性能压力依然很大。

-   **`@parcel/watcher` 的引入与移植：** Visual Studio Code 多年来一直使用由社区开发的、基于 C++ 的 `@parcel/watcher` 库，其性能表现非常出色。TypeScript 团队决定将其移植到 Go 语言。他们最初进行了一次非常直接的 C++ 到 Go 的翻译，随后逐步将其改进为更符合 Go 语言惯用语法的实现，同时保留并移植了其完整的测试套件。

-   **最终效果：**
    -   **资源效率提升：** 移植后的监听器是一个自包含的 Go 包，彻底解决了跨平台兼容性问题。它通过精细的文件系统事件追踪机制，大幅降低了对文件系统进行轮询的依赖，从而在构建增量时消耗更少的 CPU 和内存资源。
    -   **稳定性改进：** 这一改进来自于 Parcel watcher 的成熟架构，避免了因不同操作系统底层文件监听 API 的行为差异（例如 macOS 的 `FSEvents`、Linux 的 `inotify`、Windows 的 `ReadDirectoryChangesW`）而引发的各种问题。
    -   **积极的用户反馈：** 早期采用者已经验证了这一改进的效果，`--watch` 模式下的响应速度和资源占用得到了显著优化，使得 TypeScript 的自动编译体验更加流畅。

### 5. 细粒度的默认行为变更与弃用项清理

**论点：** TypeScript 7.0 继承了 6.0 版本的所有新默认行为和弃用项，并引入了新行为，旨在推动类型安全性和代码规范现代化。

**论据：**

-   **6.0 新默认值（在 7.0 中成为硬性要求）：**
    -   **`strict: true`：** 强制开启最严格的类型检查模式。
    -   **`module: esnext`** 和 **`target: ...`**：默认模块系统更新为 ES 模块，目标编译版本自动设为 `esnext` 之前的最新稳定 ECMAScript 版本，推动代码向现代标准靠近。
    -   **`noUncheckedSideEffectImports: true`**：默认启用，防止无类型声明的副作用导入被忽略。
    -   **`libReplacement: false`**：默认关闭 lib 文件替换，以避免意外冲突。
    -   **`stableTypeOrdering: true`**：强制类型输出的稳定顺序，且不可关闭，消除了构建结果的不确定性。
    -   **`rootDir: ./`** 和 **`types: []`**：这两个变化最具“惊喜”性。
        -   **`rootDir` 变化：** 如果 `tsconfig.json` 在项目根目录，而源码在 `src/` 目录下，现在需要显式指定 `rootDir: "./src"` 才能保持之前的输出目录结构。这要求开发者更明确地配置编译输出结构。
        -   **`types` 变化：** `types` 默认值从 `["*"]`（自动加载所有 `@types/*` 包）变为 `[]`（不自动加载任何类型定义）。这意味着项目必须显式列出它所依赖的 `@types` 包，例如 `types: ["node", "jest"]`。这一改变提升了项目的类型透明度，避免了因无意中引入了大量全局类型声明而导致的潜在冲突或构建缓慢问题。

-   **7.0 新行为：模板字面量类型对 Unicode 码点的正确处理**
    -   **背景：** 传统的 TypeScript 在处理类似 `"😀"` 这样的表情符号（一个 Unicode 码点由两个 UTF-16 代理对组成）时，会在模板字面量类型中将其拆分为 `\ud83d` 和 `\ude00`。
    -   **新行为：** TypeScript 7.0 改变了这一行为，使其与 JavaScript 运行时遍历字符串的行为一致（如使用 `for...of` 循环或 `[...str]` 扩展运算符）。现在，`"😀"` 在类型推断时被视作一个完整的单元。
    -   **影响：** 这是一个破坏性变更，主要影响那些有意利用 UTF-16 码元行为进行字符串长度计算或其他底层操作的类型工具。但官方认为，新行为更符合直觉，对绝大多数开发者来说更少产生令人困惑的结果。

## 四、总结与展望

TypeScript 7.0 RC 的发布标志着 TypeScript 项目进入了一个新时代。基于 Go 语言的全新编译器底座，不仅带来了 10 倍的性能飞跃，更通过智能的并行策略和高效的 `--watch` 模式，从根本上重塑了开发者的日常编译和编辑体验。同时，团队对版本过渡的思路清晰务实，通过 `@typescript/typescript6` 兼容包和 npm 别名方案，为庞大且复杂的工具链生态提供了平稳迁移的路径。虽然一些细粒度的默认行为变更和新弃用规则需要开发者留意和配置，但这些都是为了推动整个 TypeScript 生态系统向更安全、更现代、更高效的方向迈进。随着 7.0 正式版的迫近和 7.1 版本对稳定程序化 API 的承诺，TypeScript 将在“类型安全”和“极致性能”这两个维度上继续引领 JavaScript 开发的未来。TypeScript 团队强烈建议所有开发者立即下载 RC 版本，在自己的真实项目上进行测试，与社区一起将这次盛大的技术跃迁打磨得至臻完善。