MUYI · 后端工程师的生产级知识体系

Appearance

TypeScript 7 原生编译器：10 倍构建与迁移 ​

一句话定位：TypeScript 7（RC 2026-06-18，GA 2026-07-08）是把编译器与语言服务逐行从 JS 移植到 Go 的原生版——语言语义零变化，变的是实现：约 10 倍构建速度、更省内存、天然并行。这不是新语法课，是一节"工具链工程"课：微软用一次移植证明了大体量 JS 工具的性能天花板在哪。前置阅读 从Java视角看TypeScript-开篇。

1 事实底座：移植了什么、没动什么 ​

维度TS 6.x（JS 实现）TS 7（Go 原生）
语言语义完整完全一致（逐行移植，非重写语言）
编译速度基线~10x（官方口径；大仓收益更明显）
内存高（V8 GC 压力）显著下降
并行单线程为主编译天然并行
兼容—6.x 线并行维护，tsconfig 与 CLI 兼容面保持

时间线速记：2025-03 官宣（A 10x Faster TypeScript）→ 2025 内预览轮测 → 2026-06 RC → 2026-07-08 GA。

2 为什么快：三个工程决策 ​

  • 运行时换栈：V8 JIT 预热 + GC 停顿 vs Go 的静态编译与轻量协程——编译器这种"批处理型负载"是静态编译语言的主场；
  • 并行化类型检查：JS 版受单线程限制，Go 版按文件/模块粒度并行——仓越大收益越超线性；
  • 数据结构贴合：AST 与类型表用值语义数组布局，缓存局部性远好于 JS 对象图。

对照记忆：Java 侧的同款故事是 GraalVM Native Image 与 Leyden AOT（见 JDK26升级要点-HTTP3-Leyden与final语义收紧）——"用编译期确定性换运行期开销"是跨语言的共同收敛方向。

3 迁移：做什么、不用做什么 ​

  • 不用做：改类型代码、改 tsconfig 语义、改声明文件——语言层零迁移成本；
  • 要做的：工具链生态位检查——自定义 compiler plugin / 老版本 webpack loader / 依赖 TS 内部 API 的工具（transform 链）是否已发兼容 7 的版本；官方建议升级前用 7 跑一次 tsc --noEmit 对比 6.x 的报错集合，diff 为空即语义等价；
  • 渐进路径：CI 里并行跑 6/7 双编译门禁，绿一个周期再切默认——与后端灰度同一思路。

4 面试视角 ​

  • "TS 7 为什么能快 10 倍？"→ 三个词：静态运行时、并行检查、数据布局；再补一句"语义逐行移植保证不背兼容包袱"；
  • 追问"那为什么不早这么做？"→ 历史包袱：编译器 API 生态（plugin/loader）建立在 JS 实现上，换栈要整个生态跟进——工具链大版本的真实成本从来不在核心而在生态位；
  • 联动题：既然前端构建快 10 倍，CI 时长瓶颈会移到哪里？→ 测试与 e2e——考察是否真用过，而非背新闻。