Typescript 6：彩排

Source: Dev.to

请提供您希望翻译的具体文本内容，我将为您翻译成简体中文。

TypeScript 6.0 于2026年3月23日发布

如果你还没有太关注它，我可以理解。版本更新来来去去。但这个不同，值得了解原因。

同类的最后一次

• TypeScript 6 是基于 JavaScript 构建的 TypeScript 编译器的最终发布版本。
• 下一个主要版本——TypeScript 7，内部代号 Project Corsa——是用 Go 语言完全重写 的。它不是移植，也不是逐步迁移，而是从头开始用另一种语言重写编译器。

TypeScript 团队的官方公告直截了当地说明：

“TypeScript 6.0 充当 TypeScript 5.9 与 7.0 之间的桥梁。”

这不是第三方的猜测，而是微软告诉你此版本的存在是为了让你为下一步做好准备。

接下来非常重要。 基于 Go 的编译器在大约 8.7 秒 内编译 VS Code 的 150 万行 TypeScript。当前基于 JavaScript 的编译器需要 89 秒 完成同样的工作——提升了 10 倍。这不是挑选的基准，而是实际工作中的收益，改变了你的工作方式：

• 编辑器响应更快
• CI 流水线更短
• 编写代码到获知是否正确的反馈循环更快

所有这些都变得更快。

TypeScript 7 尚未确定发布日期，但官方表示 “几个月内”。 预览编译器已经可以通过 @typescript/native-preview 获取，并且已通过 99.6 % 的现有测试套件。这不是空中楼阁——已经非常接近。

TS 6 实际改变了什么

如果 TypeScript 7 是登月，那么彩排在实践中是什么样子？有三类变化重要。

1. 新默认值

如果你的 tsconfig.json 依赖宽松的默认值和隐式解析，这些假设就会失效。这是有意为之——TypeScript 6 将你推向 TypeScript 7 所需的配置。

2. 弃用

仍然在 TypeScript 6 中可用，但将在 TypeScript 7 中 硬性移除 的特性：

• target: es5 → 最低版本变为 ES2015
• --baseUrl → 改用 paths
• --outFile 打包
• --moduleResolution node 和 --moduleResolution classic（均已弃用）
• AMD、UMD 和 SystemJS 模块目标
• --downlevelIteration

您可以通过以下方式抑制这些警告：

{
  "ignoreDeprecations": "6.0"
}

但此逃生口 在 TypeScript 7 中将不存在。这只是一个暂停按钮，而不是解决方案。

3. TypeScript 7 行为预览

--stableTypeOrdering 标志让您现在就可以选择 TypeScript 7 的联合成员排序。如果您的测试对错误信息或悬停提示中类型出现的顺序敏感，此标志将在编译器切换之前提醒您。

迁移并不像听起来那么糟糕

TypeScript 团队构建了一个名为 ts5to6 的工具，能够自动处理两项最具破坏性的改动——baseUrl 的移除和 rootDir 的推断。对大多数项目而言，升级路径如下：

1. 更新你的 tsconfig，显式设置 moduleResolution。
2. 修复所有剩余的弃用警告。
3. 运行测试套件。

如果你一直保持对 TypeScript 发行版的相对更新，这通常只需要 几小时的工作——对大型 monorepo 可能需要一天。破坏性改动确实存在，但它们是 配置改动，而非语言改动。你的实际 TypeScript 代码大概率根本不需要改动。

工具考虑

更棘手的问题是编译器周边的工具会怎样变化。TypeScript 7 的基于 Go 的编译器不会再提供当前工具（如 ESLint、自定义转换器以及 IDE 插件）依赖的同样的 JavaScript API。微软在过渡期间推荐的做法是：

• 为依赖 API 的工具保留 TypeScript 6。
• 使用 原生预览（@typescript/native-preview）进行类型检查和构建。

这并不优雅，但可行，并且为生态系统争取了跟上的时间。

为什么不直接等一下？

这里正是阿波罗 10 超越普通故事的地方。

NASA 本可以跳过彩排。他们本可以省下燃料，省下任务，省下八天，直接用阿波罗 11 登陆。硬件已经准备好，软件已经准备好，机组人员也已经准备好。

但他们没有这么做，因为他们了解复杂系统的一个道理：你不是通过思考来发现问题，而是通过完整运行序列来发现问题。 阿波罗 10 的登月舱在上升分离阶段出现了一个可怕的时刻，导航模式错误导致它在月面上方失控翻转了八次。科恩在无线电中发誓。斯塔福德手动接管并在十五秒内恢复。这个错误被发现、理解并修复——因为他们进行了彩排。

如果你跳过 TypeScript 6 而直接等到 TypeScript 7，你就在 叠加两套变更。每一个已废弃的选项、每一次默认值的改变、每一个配置假设——全部在同一时间与全新的编译器运行时相冲突。你将无法分辨哪个问题是 TS 6 配置导致的，哪个是 TS 7 兼容性问题。你会在两个维度上同时进行调试。

现在就升级到 TypeScript 6，这样可以把关注点分离：

• 修复你的配置。
• 清除遗留选项。
• 让你的 tsconfig 符合 TypeScript 7 的预期。

随后，当 TypeScript 7 到来时，迁移将是一次 单一、干净的步骤——只需更换编译器二进制文件，而不是一连串的破坏性更改。

Go 编译器掉线，它是一次交换

一个变量改变，而不是二十个。

关于彩排的事

关于 Apollo 10 有一个细节让我觉得非常巧妙。短燃料并不仅仅是安全措施——它本身就是一种意图的表达。通过让机组人员不可能着陆，NASA 确保任务始终专注于它真正的目标：验证其他所有环节。没有提前跳过的诱惑。没有范围蔓延。这个约束让彩排更出色。

TypeScript 6 也有类似的特性。它并不是 Go 编译器；底层仍然是 JavaScript。但正是这种约束让它在迁移过程中变得有用。你可以在仍然运行熟悉的运行时的情况下，测试你的项目是否符合 TypeScript 7 的期望。如果出现问题，你知道是配置问题，而不是编译器本身的问题。诊断因此变得清晰。

--stableTypeOrdering 标志是整个发行版中最具 Apollo 10 特征的地方。它实际上让你预览新编译器将如何排序你的类型，这样你就可以在切换前先修正测试。这是一次 为你的彩排做的彩排。

没人记得彩排本身。Stafford、Young 和 Cernan 飞往月球并返回，而大多数人甚至说不出他们的名字。Apollo 11 获得了阅兵式的光环。TypeScript 6 也可能走同样的路——一个人们在追逐更快版本时会略过的版本号。但正是彩排让真正的着陆成为可能。

Apollo 11 在 Apollo 10 之后五十九天发射。我们并不确切知道 TypeScript 7 何时落地，但官方说法是“几个月”，而预览版已经通过了几乎所有测试套件。

彩排窗口已打开。它不会永远保持打开。

最初发表于 markbasford.info 于2026年3月30日。