英文原文：https://devblogs.microsoft.com/typescript/progress-on-typescript-7-december-2025

作者：Daniel Rosenwasser Principal Product Manager

今年早些时候，TypeScript 团队宣布我们正在将编译器和语言服务移植到原生代码（Native Code），以利用更强的原始性能、内存效率及并行处理能力。这项工作（代号“Project Corsa”，即即将到来的“TypeScript 7.0”）是一项浩大的工程，但在过去的几个月里，我们取得了长足的进步。我们很高兴能向大家同步目前的进展，并展示这套全新的 TypeScript 工具集如今已变得多么“实实在在”。

此外，我们还有关于未来路线图的消息，以及我们如何安排 TypeScript 7.0 的工作优先级，以推动移植工作的最终完成。

编辑器支持与语言服务

对于许多开发者而言，项目的重写往往在正式发布前都显得像是“纸上谈兵”。但这次不同。

TypeScript 的原生预览版目前已经做到了快速、稳定且易于使用——其中也包括了在编辑器中的体验。

TypeScript 的语言服务（即驱动编辑器中 TypeScript 和 JavaScript 功能的核心组件）也是此次原生移植工作的核心部分，并且非常容易上手试用。您可以直接从 Visual Studio Code 插件市场获取每天更新的最新版本。

尽管我们的团队仍在移植部分功能并修复小错误，但构成现有 TypeScript 编辑体验的核心要素大多已就位且运行良好。

这包括：

• 代码补全（Code Completions，包括自动导入！）
• 转到定义（Go-to-Definition）
• 转到类型定义（Go-to-Type-Definition）
• 转到实现（Go-to-Implementation）
• 查找所有引用（Find-All-References）
• 重命名（Rename）
• 快速信息/悬停提示（Quick Info/Hover Tooltips）
• 签名帮助（Signature Help）
• 格式化（Formatting）
• 选择范围（Selection Ranges）
• Code Lenses
• 调用层次结构（Call Hierarchy）
• 文档符号（Document Symbols）
• 缺失导入的快速修复（Quick Fixes for Missing Imports）

自上次重大更新以来，您可能会注意到一些显著的变化——比如自动导入、查找所有引用、重命名等。我们要知道，正是这些功能的缺失，此前阻碍了许多开发者尝试原生预览版。现在我们可以高兴地宣布，这些功能已被重新实现，并完全可以满足日常使用需求！这些操作现在适用于任何 TypeScript 或 JavaScript 代码库——包括那些使用了项目引用（project references）的项目。

我们还重新构建了部分语言服务架构，以提高可靠性，同时利用共享内存并行（shared-memory parallelism）技术。虽然有些团队反馈最初的体验偶尔会比较“容易崩溃”，但鉴于速度的提升，他们通常也能忍受。新的架构更加健壮，无论代码库规模大小，都应能轻松应对。

虽然肯定还有更多需要移植和打磨的地方，但您的团队会发现尝试 TypeScript 原生预览版是值得的。总体而言，您可以期待更快的加载时间、更少的内存占用以及更敏捷、响应更快的编辑器体验。

如果您对体验不满意，我们的插件支持在 VS Code 内置的 TypeScript 版本和新版本之间轻松切换。我们强烈建议您和您的团队今天就下载 VS Code 的原生预览版插件试一试！

编译器

TypeScript 编译器在原生移植方面也取得了重大进展。就像我们的 VS Code 插件一样，我们一直在以 @typescript/native-preview 的包名发布新编译器的每晚预览构建版（Nightly Build）。您可以通过 npm 安装：

# 本地开发依赖
npm install -D @typescript/native-preview

# 全局安装
npm install -g @typescript/native-preview

该包提供了一个 tsgo 命令，其工作方式与现有的 tsc 命令类似。两者可以并行运行。

我们要经常被问到的一个问题是：用 TypeScript 7 来验证构建是否“安全”？换句话说，它能否像 TypeScript 5.9 那样可靠地发现同样的错误？

答案是响亮的肯定的。TypeScript 7 的类型检查已近乎完成。作为背景参考，我们拥有大约 20,000 个编译器测试用例，其中约 6,000 个在 TypeScript 6.0 中会产生至少一个错误。除去 74 个用例，TypeScript 7 在其他所有用例中也都能产生至少一个错误。而这剩余的 74 个用例，都是已知的未完成工作（例如正则表达式语法检查或 isolatedDeclarations 错误），或者与已知的有意变更（弃用、默认设置更改等）有关。您今天就可以放心地使用 TypeScript 7 来检查项目中的错误。

除了单次/单项目类型检查外，命令行编译器在主要功能上也已实现对齐。诸如 --incremental（增量编译）、项目引用支持和 --build 模式等功能现已全部移植并正常工作！这意味着大多数项目只需极少的更改即可尝试原生预览版。

# 在 --build 模式下运行 tsc...
tsc -b some.tsconfig.json --extendedDiagnostics

# 在 --build 模式下运行 *新编译器*...
tsgo -b some.tsconfig.json --extendedDiagnostics

这些功能不仅可用，而且应该比 TypeScript 5.9 及更早版本（即“Strada 代码库”）中实现的版本快得多。正如我们之前所述，这部分归功于原生代码的性能，同时也得益于共享内存并行技术的使用。具体来说，这意味着 TypeScript 现在不仅可以对单个项目进行快速的多线程构建；它甚至可以并行构建多个项目！结合我们重新实现的 --incremental，在大项目的微小改动中，TypeScript 构建几乎能带来瞬间完成的感觉。

顺便提醒一下，即使不开启 --incremental，TypeScript 7 在全量构建上的速度也通常比 6.0 编译器快近 10 倍！

项目	tsc (6.0)	tsgo (7.0)	差值	提速倍数
sentry	133.08s	16.25s	116.84s	8.19x
vscode	89.11s	8.74s	80.37s	10.2x
typeorm	15.80s	1.06s	14.20s	9.88x
playwright	9.30s	1.24s	8.07s	7.51x

与 TypeScript 5.9 的预期差异

在使用新编译器时，有一些注意事项我们需要指出来。其中许多是阶段性的问题，我们计划在 7.0 正式发布前解决，但也有一些是基于长远考虑，旨在优化默认 TypeScript 体验的决定。TypeScript 7.0 的承诺意味着我们需要将重心大幅转移到新代码库上，以填补现有差距，并将新工具链交付给更多开发者。但首先，让我们深入了解一下当前的变化和限制。

弃用兼容性 (Deprecation Compatibility)

TypeScript 7.0 将移除我们在 TypeScript 6.0 中计划弃用的行为和标志。目前，您可以在我们的 Issue 追踪器上查看 6.0 中即将到来的弃用列表。一些显着的例子包括：

• --strict 将默认启用。
• --target 将默认为最新的稳定 ECMAScript 目标（例如 es2025）。
• --target es5 将被移除，es2015 将成为最低支持目标。
• --baseUrl 将被移除。
• --moduleResolution node10（即 node）将被移除，取而代之的是 bundler 和 nodenext。
• rootDir 默认为当前目录；使用 outDir 时，要么需要显式指定 rootDir，要么顶层源文件必须与 tsconfig.json 位于同一目录。

这份列表并不全面，请查看 Issue 追踪器以了解最新动态。如果您的项目依赖于任何这些已弃用的行为，您可能需要修改代码库或 tsconfig.json 以确保与 TypeScript 7.0 兼容。

我们的团队一直在尝试使用名为 ts5to6 的工具来帮助自动更新您的 tsconfig.json。该工具利用 extends 和引用的启发式算法来帮助更新代码库中的其他项目。目前它仅支持更新 baseUrl 和 rootDir 设置，但未来可能会添加更多功能。

npx @andrewbranch/ts5to6 --fixBaseUrl your-tsconfig-file-here.json
npx @andrewbranch/ts5to6 --fixRootDir your-tsconfig-file-here.json

生成 (Emit)、--watch 和 API

即使准备好了迎接 6.0，在某些情况下，新编译器仍无法立即替换旧版本。

首先，JavaScript 生成（Emit）管道尚未完全完成。如果您不需要 TypeScript 生成 JavaScript（例如，如果您使用 Babel、esbuild 或其他工具），或者您的目标是现代浏览器/运行时，那么运行 tsgo 进行构建完全没问题。但如果您依赖 TypeScript 来适配旧版运行时，我们对降级编译（downlevel compilation）的支持实际上目前仅能回溯到 es2021 目标，并且不支持编译装饰器（decorators）。我们计划解决这个问题，完全支持回溯到 es2015 的 --target，但这项工作仍在进行中。

另一个问题是，在某些场景下，新的 --watch 模式可能比现有的 TypeScript 编译器效率更低。在某些情况下，您可以寻找替代方案，例如配合 --incremental 标志运行 nodemon 和 tsgo。

最后，Corsa/TypeScript 7.0 将不支持现有的 Strada API。Corsa API 仍处于开发阶段，尚不存在稳定的工具集成。这意味着任何依赖 Strada API 的工具（如 Linter、格式化程序或 IDE 扩展）都无法与 Corsa 一起工作。

针对其中一些问题的变通方法可能是并行安装 typescript 和 @typescript/native-preview 包，在需要工具支持的地方使用 ≤6.0 API，而使用 tsgo 进行类型检查。

JavaScript 检查与 JSDoc 兼容性

我们要指出的另一件事是，我们的 JavaScript 类型检查支持（部分由 JSDoc 注释驱动）已经从头开始重写。为了简化内部结构，我们削减了一些对复杂模式以及较少使用的模式的支持，这些模式以前是被识别和分析的。例如，TypeScript 7.0 不识别 @enum 和 @constructor 标签。我们还取消了 JavaScript 中一些“宽松”的类型检查规则，例如：

• 将 Object 解释为 any，
• 将 String 解释为 string，
• 当 Foo 在 TypeScript 文件中有效时，将 Foo 解释为 typeof Foo，
• 将所有类型为 any、unknown 和 undefined 的参数视为可选参数，
• 等等。

其中一些正在此处进行审查和记录，尽管列表可能需要更新。

这意味着一些 JavaScript 代码库可能会看到比以前更多的错误，并且可能需要更新才能与新编译器良好配合。但从好的一面看，我们相信新的实现更加健壮且易于维护，并使 TypeScript 的 JSDoc 支持与其自身的类型语法保持一致。

如果您觉得我们的 JavaScript 类型检查支持中有些功能应该工作却未工作，或者是缺失了，我们鼓励您在 GitHub 仓库中提交 Issue。

展望未来

去年当我们着手重写 TypeScript 时，面临着诸多不确定性。社区会兴奋吗？代码库稳定需要多长时间？团队能多快采用这套新工具？我们能提供何种程度的兼容性？

在所有方面，结果都令我们感到惊喜。我们成功实现了一个具有极高兼容性的类型检查器。因此，微软内部和外部的项目都反馈说，他们能够毫不费力地使用原生编译器，几乎不需要额外工作。稳定性表现良好，我们有望在年底前完成大部分语言服务功能。许多团队已经在使用 Corsa 进行日常工作，且未遇到任何阻塞性问题。

随着 6.0 即将发布，我们必须考虑 JavaScript 代码库的后续安排。我们最初的计划是继续在 6.0 版本线上工作，“直到 TypeScript 7+ 达到足够的成熟度和采用率”。我们知道仍有剩余工作要做以扫清更多开发者的障碍（例如更多关于 API层面的工作），而结束 Strada 产品线（我们基于 JavaScript 的编译器）的开发，是我们尽早消除这些障碍的最佳方式。为了帮助我们尽快完成这些工作，我们正在对 Strada 项目采取一些措施。

TypeScript 6.0 是最后一个基于 JavaScript 的版本

TypeScript 6.0 将是我们基于现有 TypeScript/JavaScript 代码库发布的最后一个版本。换句话说，我们不打算发布 TypeScript 6.1，尽管在极少数情况下可能会发布补丁版本（如 6.0.1、6.0.2）。

您可以将 TypeScript 6.0 视为 TypeScript 5.9 产品线与 7.0 之间的“桥梁”版本。6.0 将弃用部分功能以与 7.0 保持一致，并在类型检查行为方面具有高度兼容性。

大多数需要编辑器端 Strada 特定功能（例如语言服务插件）的代码库，应该能够毫无困难地使用 6.0 进行编辑器操作，并使用 7.0 进行快速的命令行构建。反之亦然：开发者可以使用 7.0 在编辑器中获得更快的体验，并使用 6.0 运行依赖 TypeScript 6.0 API 的命令行工具。

TypeScript 6.0 发布后的额外维护将以补丁版本的形式进行，并且仅在以下情况下发布：

• 安全问题，
• 高严重性回归（即 5.9 中不存在的新的严重错误），
• 与 6.0/7.0 兼容性相关的高严重性修复。

与以前的版本一样，补丁发布将是不频繁的，仅在绝对必要时才会发布。

但就目前而言，我们希望确保 TypeScript 6.0 和 7.0 尽可能兼容。对于合并到 6.0 分支的开放 PR，我们将设定非常高的门槛。这从今天起生效，这意味着大多数开发者必须对 TypeScript 6.0 中解决的问题调整预期。此外，贡献者应理解，我们不太可能将 Pull Request 合并到 6.0 中，我们的绝大部分精力都将投入到实现 7.0 的功能对齐和稳定性上。我们希望在这方面保持透明，以免产生“无用功”，并避免我们的团队在两个代码库之间移植变更时出现复杂情况。

重置语言服务 Issues

虽然大多数核心类型检查代码已移植且无行为差异，但语言服务的情况则完全不同。鉴于新的架构，驱动补全、悬停提示、导航等功能的大部分代码已被大量重写。此外，TypeScript 7.0 使用标准的 LSP 协议而非自定义的 TSServer 协议，因此 TypeScript VS Code 扩展的一些特定行为可能已发生变化。

因此，任何特定于语言服务行为的错误或建议很可能无法在 7.0 产品线中复现，或者需要重新讨论。

手动验证这些问题非常耗时，因此我们将关闭与语言服务行为相关的现有 Issues。如果您遇到在该“7.0 LS Migration”标签下被关闭的问题，请在验证其可在原生每晚构建版扩展中复现后，提交一个新的 Issue。对于尚未移植到 7.0 的功能，请等到该功能出现后再提出新问题。

下一步是什么？

几个月前当我们揭晓原生预览版时，我们不得不管理大家对项目状态的预期。现在，我们可以自信地说，原生的 TypeScript 体验是真实的、稳定的，并且已准备好被更广泛地使用。但我们绝对仍在寻求反馈。

因此，我们要鼓励您安装 VS Code 原生预览版插件，在可能的情况下使用 @typescript/native-preview 编译器包，并在您的项目中进行试用。请让我们知道您的想法，并在 GitHub 仓库上提交 Issue，以帮助我们修复问题并确定下一步工作的优先级。

我们对 TypeScript 的未来充满期待，迫不及待想把 TypeScript 7.0 交到您的手中！

祝编程愉快（Happy Hacking）！