装上TypeScript 7.0 RC之后，最让我意外不是10倍提速

本来以为这会是一篇血泪踩坑实录。

结果你猜怎么着？我花了一下午时间，80%都在跟安装命令较劲，真正写代码的时候反而一帆风顺。这大概是我今年写过最拧巴的一篇了------主角是性能暴涨10倍的Go重写版TypeScript，但最值得说的不是性能，而是这玩意儿和6.0的兼容程度。

先说背景，不然你可能觉得我在吹牛

6月18号，TypeScript团队发布了7.0 RC。不夸张地说，这是TypeScript诞生以来最大的架构变革------整个编译器核心从TypeScript/JavaScript重写成了Go语言，代号Project Corsa。

官方给的数据是这样的：

VS Code代码库：编译时间从77.8秒降到7.5秒
Sentry：从133秒降到16秒
TypeORM：从17.5秒降到1.3秒
Playwright：从11.1秒降到1.1秒

平均提速10倍，内存占用减半。提速来源五五开：一半是Go语言的执行效率，一半是共享内存多线程并行。

听到这个消息，我第一反应是"不可能"。第二反应是"我要亲自试试"。第三反应是"这肯定要踩一堆坑"。

然后我就去踩了。

安装才是真正的Boss战

你知道TypeScript 7.0 RC的安装命令是什么吗？

我赌你现在脑子里想的是npm install -D typescript@7.0.0-rc。

错。

我第一次也是这么装的，然后得到一个npm报错：

less 复制代码

npm ERR! code E404
npm ERR! 404 Not Found - GET https://registry.npmjs.org/typescript/7.0.0-rc - Not Found
npm ERR! 404

看看这报错，我还以为npm抽了，刷新了好几遍网络，甚至怀疑是不是代理问题。

实际上，7.0 RC的包名是@typescript/native-preview@beta。官方故意起了个新名字，大概是强调这个版本和传统typescript包的区别。

装上的命令是：

java 复制代码

npm install -D @typescript/native-preview@beta

装完之后，我想当然地敲了tsc --version。

bash 复制代码

command not found: tsc

好家伙，连命令都变了。7.0 RC的编译器命令是tsgo，不是tsc。

这时候我才想起来看官方文档，文档里写得清清楚楚：

This beta release ships with a new command-line interface called tsgo.

问题来了------我项目里有十几个构建脚本，硬编码了tsc的地方全得改。更要命的是，有些CI/CD流水线里也写了tsc，如果没注意到这个变化，流水线直接挂给你看。

这大概是我遇到的第一个坑。但说实话，这能怪官方吗？人家文档写得清清楚楚，是我懒得看直接上手的。

VS Code用户注意了，别指望自动切换

我平时写TypeScript的主力工具是VS Code。升级完本地的tsgo之后，我习惯性地打开一个项目，准备体验飞一般的类型检查。

然后发现------VS Code右下角显示的TypeScript版本还是6.x，类型检查还是那个慢吞吞的体验。

查了一下才知道，7.0 RC的VS Code支持需要单独安装一个扩展：TypeScript Native Preview。

这个扩展不是TypeScript官方出的，是VS Code团队为了配合7.0 RC搞的。装完之后，VS Code会问你"是否切换到TypeScript Native Preview"，点一下确认才会切换过去。

说实话，这个设计有点迷惑。如果不是刻意去看文档，普通用户可能根本不知道还需要装这个扩展。

让我意外的事情发生了

安装折腾完之后，我终于开始用7.0 RC写代码了。

我的项目里有一万多行TypeScript代码，涵盖业务逻辑、工具函数、React组件、Node服务各种场景。我本来做好了心理准备------Go重写的编译器，行为肯定和6.0有差异，万一碰到什么类型检查不一致的地方，又要花时间调试兼容。

结果呢？

什么都没发生。

我盯着终端等了半天，愣是没等到它报错。跑了完整的类型检查，和6.0的结果完全一致。没有新增报错，没有语义变化，没有任何breaking changes的感觉。

我当时就愣住了，心想：就这？我折腾了一下午的安装，就为了体验这个"什么都没发生"？

我以为是编译器哪里出了问题，专门去翻了一下官方公告。公告里是这么写的：

TypeScript 7.0 maintains 100% semantic compatibility with TypeScript 6.0.

翻译一下就是：7.0和6.0的语义完全兼容。官方说他们采用了一种"逐行翻译"的策略，把TypeScript/JavaScript写成的6.0编译器翻译成Go，没有改变任何类型检查的逻辑。所有改动都经过了十年的测试套件验证。

好家伙，我以为Go重写意味着各种breaking changes，结果人家官方比你还怕出事。

真正的坑在这里------deprecated配置变硬错误

当然，7.0 RC也不是一点问题都没有。

有一个场景确实会报错：某些从6.0就开始deprecated的配置项，在7.0变成了硬错误。

比如你在tsconfig.json里写了这些：

json 复制代码

{
  "compilerOptions": {
    "module": "commonjs",
    "moduleResolution": "node",
    "target": "es5",
    "baseUrl": "."
  }
}

在6.0时代，这些配置会给你一个warning，说"这写法过时了，建议改成xxx"。到了7.0 RC，直接给你报错，编译直接失败。

这是唯一的breaking changes来源------但说实话，这不是Go重写带来的，是6.0就开始埋的雷。

官方的迁移建议很明确：先升级到TypeScript 6.x，处理掉所有deprecated警告，再尝试7.0 RC。

我照做了。我先在项目里跑了6.0版本的编译，把那些deprecated配置全部改掉，大概花了半小时。然后切换到7.0 RC，一次过。

速度和稳定性，我选稳定性

说了这么多，还没正儿八经测性能。

我用tsgo跑了一下我们项目的类型检查，时间从原来的35秒左右降到了3.5秒左右。官方说的10倍提速，在我的场景里基本验证了。

但这不是最让我惊讶的。

最让我惊讶的是语言服务器命令的稳定性。官方说7.0的语言服务器命令失败率只有6.0版本的1/20。我不知道这个数字怎么测的，但实际体验下来确实流畅很多。

以前在VS Code里，偶尔会遇到TypeScript服务抽风------突然报一堆莫名其妙的红错，或者智能提示完全消失，重载好几次才能恢复正常。用了7.0 RC之后，这种抽风基本没再出现过。

我现在把7.0 RC当主力TypeScript版本用了。

不是因为10倍提速------虽然这很香。是因为它太稳了，稳得不像一个RC版本。

写在最后

TypeScript 7.0 RC用Go重写，这事儿听起来很激进。但真正上手之后，我发现它其实是保守的------保守到几乎没有给现有项目带来任何迁移成本。

如果你的项目用6.0跑得好好的，升级到7.0 RC基本上不会遇到问题。唯一需要做的就是检查一下tsconfig.json，把那些deprecated的配置项处理掉。

安装命令记住：npm install -D @typescript/native-preview@beta，编译用tsgo。

所以你看，最让我意外的，不是10倍的速度，而是它带来的"无感"升级。这种"无感"，或许才是对开发者最大的尊重。