TypeScript 7 进度 – 2025-12（译）

发表于 更新于 分类于 本文字数： 3.9k 阅读时长 ≈ 14 分钟

前言

今年早些时候， TypeScript 团队宣布正在将编译器和语言服务移植到原生代码上，以此获得更好的原始性能，内存占用以及并行能力。这项努力（代号 “Project Corsa” ，很快将改名为 “TypeScript 7”）是一项重大的任务，但过去的几个月我们取得了巨大的进步。我很激动能在此给大家提供一些最新的消息，并且展示新版的 TypeScript 工具集是有多么的实用。

我们带来了有关即将到来的路线图，以及我们如何优先开发 TypeScript 7.0 以推动移植工作顺利完成的消息。

正文

编辑器支持以及语言服务

对大多数开发者来说，一个项目的重写，在最终发布之前可能会感觉完全处于理论阶段。但这次并非如此。

TypeScript 原生版本快速，稳定，并且易于使用，即使在编辑器中也是如此。

TypeScript 的语言服务（也就是那个在编辑器中为你提供 JavaScript 和 TypeScript 功能的东西）也是原生迁移工作的核心部分。你可以在 VSCode 插件市场上获取每天构建的最新版本

我们的团队仍然在持续地迁移功能以及修复 bug ，但现有的 TypeScript 已具备大多数编辑体验上的功能，并且它们运行良好。

这些功能包括：

  • 代码完成（包含自动导入）
  • 转到定义
  • 转到类型定义
  • 转到实现
  • 寻找所有引用
  • 重命名
  • 悬浮提示
  • 签名提示
  • 格式化
  • 范围（智能）选择
  • 代码透镜
  • 调用层级
  • 文档符号
  • 快速导入缺失依赖

你可能注意到了自上个主要版本更新以来所添加的功能，比如自动导入，寻找所有引用，重命名等等。我们知道这些功能的缺失让许多想尝试原生版本的开发者打了退堂鼓，所以很开心地告诉大家这些功能已经在预览版上实现了并且准备好用于日常使用了！这些操作现在可以在任何 TypeScript 或者 JavaScript 代码库上工作，这也包括那些带有项目引用的代码库。

我们还重构了部分的语言服务代码，利用了共享内存的并行性提升了可靠性。一些团队报告最初使用时的体验有点“令人崩溃”，但速度的提升使得他们能够容忍这一情况。新的架构更加的健壮，能够正常处理大规模或小规模的代码库。

虽然功能上仍有很多需要迁移和打磨的地方，但是你的团队可能会发现尝试原生 TypeScript 是值得的。你可以同时期待更快的加载速度，更少的内存使用，以及响应更快的编辑器。

如果你曾经对体验不满，我们的扩展简化了切换 VSCode 内置 TypeScript 和原生 TypeScript 的功能。我们真的鼓励你和你的团队尝试这个扩展。

编译器

TypeScript 编译器在原生迁移上也取得了显著的进展。如同我们的 VSCode 扩展一样，我们也发布了新编译器的每天构建版本，包名为 @typescript/native-preview 。你可以通过 npm 命令来安装它，如下：

1
2
3
4
5
# local dev dependency
npm install -D @typescript/native-preview

# global install
npm install -g @typescript/native-preview

这个包提供了一个 tsgo 的命令，它和现存的 tsc 命令很相似，这两者可以一起使用。

我们经常被问道“能否通过 TypeScript7 验证构建是否安全”的问题，换句话说就是“它能和 TypeScript 5.9 一样可靠地发现相同的错误吗？”。

我可以坚定地回答，可以！TypeScript 7 的类型检查近乎完成。为了便于理解，我们编写了大约 2000 个编译器测试用例，其中大约 6000 个在 TypeScript 6.0 下会产生至少一个错误。除了 74 个用例之外 TypeScript 7 也产生至少一个错误，在剩余的 74 个用例中，所有问题都是已知的未完成的工作（比如，正则表达式语法检查或者 isolatedDeclarations 错误）或者与已知的有意改变相关（弃用，默认设置变更等等）。如今你已经可以自信地使用 TypeScript 7 来检查项目中错误了。

除了单次/单项目的类型检查，命令行编译器已经达到了同等的水平。像 --incremeental 标志，项目引用支持， --build 模式等功能目前都已移植并且正常工作。这意味着许多项目只需要极少的变更即可切换到原生 TypeScript 上。

1
2
3
4
5
# Running tsc in --build mode...
tsc -b some.tsconfig.json --extendedDiagnostics

# Running the *new compiler* in --build mode...
tsgo -b some.tsconfig.json --extendedDiagnosticsv

除了这些功能变得可用外，它们的执行速度也比现存的 TypeScript 5.9 或更旧的版本要快得多（又名 Strada 代码库）。正如我们先前描述的那样，这不仅源自原生代码的性能，也来自共享内存并行性的使用。更具体来说这意味着 TypeScript 现在不仅可以在一个项目上通过多个线程快速构建，也可以并发构建多个项目。结合我们对 --incremental 的重新实现，我们即将在大项目的构建中让 TypeScript 对微小的变更也能立即完成。

注意，即使不使用 --incremental ，在全量构建下，TypeScript 7 对比 TypeScript 6 仍然能有大概接近 10 倍的速度提升.

Project tsc (6.0) tsgo (7.0) Delta Speedup Factor
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 的到来意味着我们需要将精力更多地放在新的代码库上来缩小与现存功能的差距，以及将新的工具交付给更多的开发者。不过目前我们先深入了解下当前的一些变更和限制。

弃用兼容性

TypeScript 7.0 将会删除那些计划在 TypeScript 6.0 弃用的行为标志。现在，你可以点此查看 TypeScript 6.0 即将弃用的列表。一些突出的例子如下：

  • --strict 默认启用
  • --target 默认设置为 ECMAScript 当前的稳定版本（比如， es2025 ）
  • --target es5 将被移除， es2015 将成为最低支持目标
  • --baseUrl 将被移除
  • --moduleResoltion node10 （又称 node ）将被移除，取代它的是 bundler 和 nodenext
  • rootDir 默认设置为当前文件夹，使用 outDir 要么显式指定 rootDir ，要么顶层源文件必须和 tsconfig.json 文件位于统一目录下

上面提到的只是一部分，可以点此查看更多信息。如果你的项目依赖任何这些弃用的行为，你可能需要修改你的代码库或者 tsconfig.json 文件来确保兼容 TypeScript 7.0 。

我们的团队发布了一个实验性质的工具 ts5to6 来帮你自动更新 tsconfig.json 文件。该工具
在 extends 和 references 字段上使用启发式方法来协助更新代码库中的其他项目。目前它只能更新 baseUrl 和 rootDir 设置，未来会支持更多的选项。

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

输出，–watch 以及 API

即使 TypeScript 6.0 已经可用，但仍有一些情况无法立即替换为新的编译器。

其中的一个情况是，JavaScript 输出管道还未完全完成。如果你不需要 从 TypeScript 输出到 JavaScript （比如，如果你使用了 Babel ， esbuild 或者其他工具），或者你的目标是现代浏览器或者运行时，使用 tsgo 来构建完全可以。但是如果你依赖 TypeScript 打包到旧运行时的话，目前只支持降级编译到 es2021 ，并且不支持编译装饰器。我们计划 --target 标志最小支持到 es2015 ，不过功能仍然还在实现中。

另一个问题是新的 --watch 模式在某些场景下可能会比现存的 TypeScript 编译器的效率要低。在某些情况下你可以通过使用 nodemon 和带有 --incremental 标志的 tsgo 命令来解决它。

最后， Corsa（也就是 TypeScript 7.0 ）将不支持现存的 Strada API 。 Corsa API 仍在实现中，还没有稳定的工具集成方案。这意味着任何依赖 Strada API的工具，比如代码检查工具，代码格式化工具或者 IDE 扩展将无法再 Corsa 下工作。

一部分问题可以通过同时安装 typescript 包和 @typescript/native-preview 包来解决。需要 <=6.0 API 的工具使用现存的 TypeScript ，而代码检查则使用 tsgo 来完成。

JavaScript 检查和 JSDoc 兼容

另一件我们想宣布的是我们从 0 开始重写了 JavaScript 的类型检查支持功能（部分通过 JSDoc 注解驱动）。为了简化内部的逻辑，我们去除了对一些先前识别和分析过的，复杂以及较少使用模式的支持。比如，TypeScript 7.0 不再识别 @enum 和 @constructor 标签。我们还将删除 JavaScript 中一些“宽松”的类型检查规则，比如下面这些类型误判的例子：

  • 将 Object 当作 any
  • 将 String 当作 string
  • 当 typeof Foo 在一个 TypeScript 文件中合法时，将 Foo 当作 typeof Foo
  • 将所有 any ， unknown 和 undefined 类型的参数当作可选参数

这个 PR 记录了这些信息，这个列表可能需要更新。

这意味着一些 JavaScript 代码库可能会观察到比之前更多的错误，需要更新代码来适配新编译器。此外，我们相信新的实现更加健壮以及可维护，并使 TypeScript 的 JSDoc 支持和它自身的类型语法保持一致。

如果你在 JavaScript 类型检查中发觉某些情况应该被处理，又或是缺失了某些支持，我们鼓励你在我们的仓库中发起一个 issue 。

聚焦未来

当去年我们开始重写 TypeScript 的时候，有很多不确定的因素。社区会对此感到兴奋吗？需要多久才能在代码库上稳定使用？团队得多快才能适应新的工具集？我们可以达到什么样的兼容程度？

结果是各方面都让我们感到惊喜，我们实现了一个极高兼容性的类型检查器。因此，微软内外部的项目都表示他们以很小的努力就能轻松地使用这个原生的编译器，它的稳定性也在提高，并且我们计划在年底完成更多的语言服务功能。许多团队已经开始在每天的工作中流畅地使用 Corsa（TypeScript 7.0 ）

随着 6.0 即将来临，我们不得不考虑 JavaScript 代码库的下一步计划。我们初始的计划是继续在 6.0 版本线上开发，直到 TypeScript 7+ 达到足够成熟和采用。为了让更多开发者拥抱 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 和 TypeScript 7.0 的一座桥。6.0 将会弃用一些功能来对其 7.0 ，并且高度兼容 7.0 的类型检查行为。

许多需要编辑器测特定 Strada 功能的代码库（比如语言服务插件LSP）可以使用 6.0 来支持那些编辑器功能，7.0 则用来快速进行命令行构建，这样不会遇到过多麻烦。反过来也可以：开发者可以使用 7.0 来支持那些更快的编辑器体验，然后对那些使用 6.0 API 的功能使用 6.0 的命令行工具。

TypeScript 6.0 发布后的额外服务将以修补版本的形式，只在以下情况下进行发布：

  • 安全问题修复
  • 新高危问题修复（比如 5.9 没出过的新的严重的 bug）
  • 与 6.0/7.0 兼容性相关的高危问题修复

与先前发布的版本一样，修补版本发布的频率不会很频繁，只有绝对必要的时候才会发布。

但就目前而言，我们想要确保 TypeScript 6.0 和 7.0 尽可能地兼容。我们将严格控制哪些为解决地 PR 会被合并到 6.0 的版本线中。这条规定从今天起生效，这意味着许多开发者将不得不明确哪些问题应该在 TypeScript 6.0 中解决，将更多的精力放在使 7.0 平衡和稳定这件事上。我们想要在这方面保持透明，这样就不会出现“浪费”的工作，同时也能让我们的团队避免在两个代码库之间迁移时产生复杂的情况。

重置语言服务问题

虽然大部分的核心类型检查都已迁移，并且没有任何行为上的不同，但语言服务是一个例外。在新的架构下，驱动代码完成，悬停提示，导航等等功能的代码，已大幅度重写。另外， TypeScript 7.0 使用标准的 LSP 协议而不是自定义的 TSServer 协议，所以 VSCode 的 TypeScript 扩展的一些特定的行为可能会变更。

因此，任何关于语言服务行为的 bug 和建议可能不会再 7.0 版本中复现，或者需要重新讨论。

这些问题手动验证起来很耗时，所以我们将关闭与语言服务行为有关的 issue 。如果你遇到了以“7.0 LS Migration” 标签关闭的 issue ，请在每日构建版本的扩展下验证复现后提交一个新的问题。对于哪些还未迁移到 7.0 的功能，请在功能完成发布后再提交 issue 。

下一步

当我们在几个月前宣布转到原生代码时，我们必须管理好大家对项目状态的预期。而现在我们到了一个我们可以自信地说出“原生 TypeScript 的体验是真实，稳定的，并且已经准备好被广泛使用了”的这一阶段。当然我们仍然希望得到用户的反馈。

所以我们鼓励你安装 VSCode 的原生 TypeScript 扩展，在任何你觉得可以的地方使用 @typescript/native-preview 包，也可以在项目中尝试使用。我们希望了解你的使用感受，你也可以在我们的仓库上提问题来帮我们修复以及确定下一步优先考虑的工作。

我们对 TypeScript 的未来充满兴奋，我们也迫不及待地想让你体验 TypeScript 7.0 了。