十倍提速而且是用 Go 重写。微软刚刚扔出的 TypeScript 7.0 RC 版直接在前端圈砸出了个大水坑。这可不是什么常规的版本迭代而是整个底层架构的一次逆向重写。长期以来TS 的慢是出了名的。编译时能去冲杯咖啡甚至上个厕所并不是段子。Node.js 毕竟是解释执行一旦项目规模达到几百万行类型检查 and 编译能把机器卡得直冒烟。但这次微软抛弃了自举用 Go 把整个编译器重写了一遍编译速度直接飙了十倍。在技术圈大家以前很看重“自举”也就是用自己写自己。TS 以前一直是用 TS 写、编译成 JS 跑。微软这次想明白了与其为了“自举”的虚名死撑不如直接用系统级语言重构。他们最终选了 Go。通过原生代码运行和 Go 优秀的共享内存并行能力整个类型检查的底层逻辑彻底被解绑了。其实就是这次 7.0 默认会启动 4 个 Checker Worker可以通过--checkers调整。这些 Worker 会并行去干活充分榨干你多核 CPU 的性能。如果你的 CI 服务器配置了 16 核你可以把这个值调大编译速度还能再往前蹿一蹿。当然内存消耗也会跟着涨低配置的机器可别乱开。另一个平时天天用、但经常把 CPU 吃满的功能是 watch 模式。7.0 重建了整个监听机制直接移植了 Parcel 构建工具的底层监听器。这个监听器原本是用 C 写的因为微软不想在 Go 的编译流程里引入一整套 C 工具链那会让安装变得极其折腾所以硬是用 Go 汇编做了一些精巧的衔接把它翻译成了纯 Go 版本。监听不仅极其稳定而且在 node_modules 里躺了成千上万个文件时CPU 依然能保持冷静。不过十倍性能的飞跃不是免费的。为了让这个 Go 语言重写的新编译器跑得爽微软顺手把积攒了多年的历史烂账给一刀切了。如果你准备把老项目往 7.0 升级估计你得先脱一层皮。第一个大砍刀挥向了target: es5和downlevelIteration。直接后果就是7.0 彻底放弃了编译生成 ES5 时代的代码。如果你的项目还在兼容一些老旧浏览器7.0 会直接报硬错误。你只能在打包阶段交给 Babel 或者 Webpack 来做降级TS 不伺候了。第二刀砍掉了baseUrl。在以前为了写路径别名大家喜欢在 tsconfig 里设置一个 baseUrl然后写一堆相对路径。这其实是一个历史包袱在 7.0 里它不再被支持了。你需要把 paths 全都改成相对于项目根目录的相对路径。如果你的项目里有几十处依赖 baseUrl 的地方升级时得挨个去修改路径头皮发麻是免不了的。还有就是moduleResolution: classic和moduleResolution: node/node10。这些古老的模块解析模式全都被废弃了。取而代之的是bundler或者nodenext。这对于还在使用老旧脚手架的旧项目来说升级后可能会有一堆库莫名其妙地找不到路径需要花大量时间去折腾模块配置。此外如果你在写 JavaScript 文件的 JSDoc 注释7.0 也不再认一些野路子语法了。比如以前用enum来标注枚举或者随便写一个独立问号?代表任意类型在 7.0 里全部罢工你必须规规矩矩地用标准的typedef或者是typeof。这其实是微软在强行把 JS 的类型检查标准往 TS 靠拢。所以TS 7.0 确实是一剂性能猛药但它不是无痛的。对于大项目来说编译快十倍的诱惑力大到让人无法拒绝哪怕升级的时候要花几天时间去重构配置和清理老旧依赖这笔买卖也绝对划算。你打算在第一天就给项目升级吗反正我是准备先拿个分支去趟趟水了。·······END·······喜欢的话可以点个赞关注博主哦
【前端分享】ript 7.0 RC 发布 用 Go 重写狂飙 10 倍，但也清算了一堆旧账！
十倍提速而且是用 Go 重写。微软刚刚扔出的 TypeScript 7.0 RC 版直接在前端圈砸出了个大水坑。这可不是什么常规的版本迭代而是整个底层架构的一次逆向重写。长期以来TS 的慢是出了名的。编译时能去冲杯咖啡甚至上个厕所并不是段子。Node.js 毕竟是解释执行一旦项目规模达到几百万行类型检查 and 编译能把机器卡得直冒烟。但这次微软抛弃了自举用 Go 把整个编译器重写了一遍编译速度直接飙了十倍。在技术圈大家以前很看重“自举”也就是用自己写自己。TS 以前一直是用 TS 写、编译成 JS 跑。微软这次想明白了与其为了“自举”的虚名死撑不如直接用系统级语言重构。他们最终选了 Go。通过原生代码运行和 Go 优秀的共享内存并行能力整个类型检查的底层逻辑彻底被解绑了。其实就是这次 7.0 默认会启动 4 个 Checker Worker可以通过--checkers调整。这些 Worker 会并行去干活充分榨干你多核 CPU 的性能。如果你的 CI 服务器配置了 16 核你可以把这个值调大编译速度还能再往前蹿一蹿。当然内存消耗也会跟着涨低配置的机器可别乱开。另一个平时天天用、但经常把 CPU 吃满的功能是 watch 模式。7.0 重建了整个监听机制直接移植了 Parcel 构建工具的底层监听器。这个监听器原本是用 C 写的因为微软不想在 Go 的编译流程里引入一整套 C 工具链那会让安装变得极其折腾所以硬是用 Go 汇编做了一些精巧的衔接把它翻译成了纯 Go 版本。监听不仅极其稳定而且在 node_modules 里躺了成千上万个文件时CPU 依然能保持冷静。不过十倍性能的飞跃不是免费的。为了让这个 Go 语言重写的新编译器跑得爽微软顺手把积攒了多年的历史烂账给一刀切了。如果你准备把老项目往 7.0 升级估计你得先脱一层皮。第一个大砍刀挥向了target: es5和downlevelIteration。直接后果就是7.0 彻底放弃了编译生成 ES5 时代的代码。如果你的项目还在兼容一些老旧浏览器7.0 会直接报硬错误。你只能在打包阶段交给 Babel 或者 Webpack 来做降级TS 不伺候了。第二刀砍掉了baseUrl。在以前为了写路径别名大家喜欢在 tsconfig 里设置一个 baseUrl然后写一堆相对路径。这其实是一个历史包袱在 7.0 里它不再被支持了。你需要把 paths 全都改成相对于项目根目录的相对路径。如果你的项目里有几十处依赖 baseUrl 的地方升级时得挨个去修改路径头皮发麻是免不了的。还有就是moduleResolution: classic和moduleResolution: node/node10。这些古老的模块解析模式全都被废弃了。取而代之的是bundler或者nodenext。这对于还在使用老旧脚手架的旧项目来说升级后可能会有一堆库莫名其妙地找不到路径需要花大量时间去折腾模块配置。此外如果你在写 JavaScript 文件的 JSDoc 注释7.0 也不再认一些野路子语法了。比如以前用enum来标注枚举或者随便写一个独立问号?代表任意类型在 7.0 里全部罢工你必须规规矩矩地用标准的typedef或者是typeof。这其实是微软在强行把 JS 的类型检查标准往 TS 靠拢。所以TS 7.0 确实是一剂性能猛药但它不是无痛的。对于大项目来说编译快十倍的诱惑力大到让人无法拒绝哪怕升级的时候要花几天时间去重构配置和清理老旧依赖这笔买卖也绝对划算。你打算在第一天就给项目升级吗反正我是准备先拿个分支去趟趟水了。·······END·······喜欢的话可以点个赞关注博主哦
