TypeScript 7.0 正式發布：Go 原生移植讓完整建置快 8–12 倍，VS Code 內建支援

編按：本文綜合整理自 Microsoft TypeScript Blog〈Announcing TypeScript 7.0〉、VS Code Team〈Iterating faster with TypeScript 7〉、Visual Studio Magazine〈TypeScript 7.0 RC Moves Microsoft’s Go Rewrite Into the Mainline Compiler〉 及 Hacker News 上 198 則工程師討論，並加入 Siami 編輯部觀點與延伸研究。

TypeScript 團隊 7 月 8 日正式釋出 TypeScript 7.0——這是 TypeScript 編譯器與語言工具鏈的 Go 原生移植版本，在 Hacker News 衝上 373 分、198 則留言，是本月最被討論的前端基礎建設新聞。官方公布的實測數據顯示，完整建置時間普遍縮短 8 到 12 倍，記憶體用量同步下降。在 VS Code 上開啟一個有錯的檔案，從過去的 17.5 秒縮短到 1.3 秒，速度提升超過 13 倍。

這不只是一次性能升級——它是 TypeScript 誕生 14 年來，第一次把整個編譯器從 JavaScript 改寫到另一個語言的徹底改造。

一年前就開始的移植計畫

Microsoft 在 2025 年 3 月首次公開這個移植計畫，目標是讓 TypeScript 工具鏈的每一個環節都快一個數量級。整個專案的核心做法是用 Go 從零重建整個編譯器，但盡可能保留原本 JavaScript 版本的結構與邏輯，確保兩個編譯器在結果上完全相容。

這個選擇背後的工程權衡很清楚：

• 原生程式碼速度：放棄 JavaScript 引擎的 JIT，改用 Go 的 AOT 編譯產物，從根本解決大型專案的編譯瓶頸
• 共享記憶體多執行緒：Go 的 goroutine 與 channel 模型讓 type-checker、parser、emitter 可以平行跑，這是 JavaScript 單執行緒模型做不到的
• 新最佳化空間：在 Go 程式碼基礎上重整資料結構與演算法，官方宣稱典型建置可達 8–12 倍加速

過去一年，VS Code、Loop、Office、Power BI、Teams、Xbox 等 Microsoft 內部團隊，以及 Bloomberg、Canva、Figma、Google、Lattice、Linear、Miro、Notion、Sentry、Slack、Vanta、Vercel、VoidZero 等公司都參與了內測。

實測數字：vscode 專案從 125.7 秒降到 10.6 秒

官方公布的開源專案基準測試結果（單機環境，預設 4 個 type-checker worker）：

記憶體使用量同樣顯著下降：

如果把 --checkers 從預設 4 調到 8，vscode 專案進一步降到 7.51 秒，速度提升 16.7 倍。這意味著硬體資源越多、加速越明顯，但代價是記憶體使用量會增加——團隊可以依機器規格與專案大小調整。

平行化架構：parser、type-checker、emitter 全面重構

TypeScript 7.0 最關鍵的架構改變是全面平行化。建置流程中的解析、型別檢查、產出檔案三個階段，現在可以同時跑：

• 解析（parsing）：各檔案獨立，直接 scale 到 CPU 核心數
• 型別檢查（type-checking）：建立固定數量的 type-checker worker，每個 worker 各自維護「對世界的看法」。雖然可能重複運算，但給定相同輸入，永產出相同結果——這是 determinism 與平行化的權衡
• 產出檔案（emitting）：各檔案獨立 emit

預設 --checkers 4，可用 --checkers 8（vscode 從 11.9x → 16.7x）或 --checkers 1（CI runner 等資源受限環境）。新增的 --builders 旗標控制 monorepo 多專案平行建置的數量。新增 --singleThreaded 旗標可在除錯或比較 6.0 / 7.0 表現時強制單執行緒。

watch 模式：移植自 Parcel 的跨平台檔案監看

--watch 模式整個重寫了。TypeScript 團隊原本在 Go 找不到理想的跨平台檔案監看方案，自己實作的輪詢機制在大規模 node_modules 下太耗資源。最後決定把 VS Code 用多年的 Parcel watcher 從 C++ 移植到 Go，加上一層組合語言 shim 避免引入 C++ 工具鏈依賴。

這個移植案意外成了 TypeScript 對上游的貢獻——devon govett（Parcel 作者）的作品現在同時服務 VS Code 與 TypeScript 兩個生態系。

editor 體驗：LSP 介面、多執行緒、VS Code 內建

TypeScript 7.0 語言伺服器改用 Language Server Protocol（LSP） 介面，並原生支援多執行緒——一個 request 不再 block 整個編輯器。半年來補齊了 auto-imports、expandable hovers、inlay hints、code lenses、go-to-source-definition、JSX linked editing、tag completions 等功能。原本 beta 缺掉的 semantic highlighting、sort imports、remove unused imports 全部回歸。

VS Code 7 月底前會內建 TypeScript 7 支援，安裝專用擴充可立即啟用；Visual Studio 17.x 會依 workspace 自動啟用。官方公布的語言伺服器崩潰率比 6.0 下降 60%、失敗指令下降 80%。

但有一個重要限制：TypeScript 7 尚未提供穩定的 programmatic API，這代表 Vue、Astro、Svelte、MDX 等依賴 Volar 嵌入 TypeScript 的框架，短期內只能繼續用 6.0。Angular 專案可以用 7.0 跑 CLI 檢查，搭配 6.0 做 editor 支援。

預設行為改變與重大破壞性更新

TypeScript 7.0 採用 6.0 的新預設值，所有在 6.0 被標 deprecate 的旗標與寫法都變成 hard error。幾個最值得注意的變更：

預設值改變：

• strict 預設為 true
• module 預設為 esnext
• target 預設為 esnext 前一個穩定 ECMAScript 版本
• noUncheckedSideEffectImports 預設為 true
• libReplacement 預設為 false
• stableTypeOrdering 預設為 true（無法關閉）
• rootDir 預設改為 ./（巢狀原始碼目錄需明確設定）
• types 預設改為 []（舊行為可設為 ["*"] 還原）

變成 hard error 的 deprecations：

• target: es5 不再支援
• downlevelIteration 不再支援
• moduleResolution: node/node10/classic 全數移除，建議改用 nodenext 或 bundler
• module: amd/umd/systemjs/none 不再支援
• baseUrl 不再支援，paths 改為相對於專案根目錄
• esModuleInterop、allowSyntheticDefaultImports 不可設為 false
• module 關鍵字不能在 namespace 宣告中使用
• asserts 關鍵字不能用在 import，必須改用 with（對齊 ECMAScript 的 import attribute 語法）
• 帶 tsconfig.json 的目錄下，命令列建置不能直接傳檔案路徑（除非加 --ignoreConfig）

Template literal type 的 Unicode 處理也改了：以前 "😀abc" 在型別推導會被切成 ["\ud83d", "\ude00abc"]（surrogate pair），現在正確切成 ["😀", "abc"]——這是 breaking change，但對 99% 的使用者更直觀。

升級路徑：先用 6.0 staging branch 過一輪

官方強烈建議先升到 TypeScript 6.0（在 stableTypeOrdering: true 且無 ignoreDeprecations 旗標下），確認 6.0 通過，再升 7.0。這樣可以分兩階段處理破壞性變更，避免一次 debug 太多東西。

安裝方式：

# 穩定版
npm install -D typescript

# 還想停留在 6.0 的專案
npm install -D @typescript/native-preview
# 或
npm install -D typescript@next  # 7.0 夜間建置

nightly build 會從 @typescript/native-preview 搬回 typescript@next——過去這顆套件已經有 每週 850 萬次下載，是社群最活躍的 TS 7 測試管道。

為什麼這件事重要

這是 JavaScript 生態系近年來最重大的基礎建設更新之一：

• CI 成本是 SaaS 公司最大的隱藏開銷之一。一家 50 人的 SaaS 公司，CI 若用 8 分鐘跑完整建置，工程師每天等 CI 的時間加總可能高達 10–20 人時。8–12 倍速度等於直接把雲端費用砍掉 80%，並把 iteration loop 從「寫 5 分鐘、等 8 分鐘」變成「寫 5 分鐘、等 1 分鐘」——這是 PMF 階段初創公司最缺的競爭力。
• AI 程式設計代理讓 build time 成為新的瓶頸。Claude Code、Cursor、Copilot 這類工具每秒能產生大量程式碼，瓶頸已經不是「寫 code」而是「等編譯」。TypeScript 7 把這個瓶頸直接砍掉一個量級，等於把 AI 寫 code 的 ROI 拉高 10 倍。這跟 SWE-bench、Devin、Cognition SWE-1.7 是同一條趨勢線：模型能力 × 工具速度的乘積才是真正的生產力。
• 這是 JavaScript 引擎被原生編譯語言超越的最新證據。從 esbuild、Vite、Rspack、Bun 到現在的 TypeScript Go port，整個前端工具鏈都在經歷「JS 寫底層工具」被「Go/Rust 原生」取代的過程。V8 的 JIT 速度再快，也快不過 AOT 編譯 + 多執行緒。
• Microsoft 把核心 infra 從 JS 搬到 Go，是給整個產業的訊號：連微軟自己都不相信 JavaScript 適合做高效能編譯器了。

數據解讀與質疑

幾個常被忽略的細節：

• 「10x faster」是 full-build 數字，不代表所有操作都快 10x。Cold start 跟 large-scale 編譯任務加速最明顯；小專案或 incremental build 提升較小。
• 平行化的代價是記憶體。--checkers 8 vscode 從 11.9x 加速到 16.7x，但 8 個 worker 各持有「對世界的看法」代表記憶體使用量會增加。CI runner（常見 2 vCPU / 4 GB）不適合開 8 checkers，反而 --checkers 1 比較安全。
• 官方 vscode 數字是「絕對秒數」基準，但官方也承認獨立 benchmark 結果會依硬體、作業系統、模組大小不同而異。GitHub 上有開發者貼出跨平台獨立驗證（typescript-go#4410），可以參考。
• Volar 生態系的過渡期是真正陣痛。Vue 3.5、Angular 18+、Astro 4、Svelte 5 這些框架依賴 TypeScript 的 API embedding，短期內 TS 7 在 editor 內的體驗可能比 TS 6 差。官方承諾會儘快提供穩定 API，但沒給時間表。
• nightly build 從 @typescript/native-preview 搬回 typescript@next——已經有 850 萬週下載的套件名稱會改變，依賴這個套件名稱的 CI script 要更新。
• Hacker News 上已經有人在討論 swc、oxc 會不會成為下一個被原生重寫的對象。TypeScript 證明了「JS 寫底層工具」是會被淘汰的，整個工具鏈的下一輪重寫可能會是 SWC、Rome/Biome、Vitest 這類。

社群反應：monorepo 玩家狂喜，Volar 維護者皺眉

Hacker News 上 198 則討論的共識是：monorepo 跟大型 codebase 玩家是最大受惠者。有 Slack 工程師回報，TypeScript 7 讓 CI merge queue 時間直接砍掉 40%——這在 release day 流量下等於讓 hotfix 早 20 分鐘上線。

但 Volar（Vue 官方語言伺服器）維護者跳出來提醒：TS 7 沒有 stable programmatic API，所以 Vue / Svelte / MDX / Astro 短期內只能繼續用 TS 6。這對前端生態是過渡期陣痛，官方承諾會儘快提供 API，但沒給時間表。

對 TypeScript 6.0 升級還沒完成的團隊，這次升級的時程壓力會更重——6.0 跟 7.0 的 deprecations 一次到位，沒有分階段遷移的餘裕。

TypeScript 團隊在文末寫道：「Welcome to the native era of the TypeScript toolset.」（歡迎來到 TypeScript 工具鏈的原生時代。）這句話不只是技術宣示——它是整個 JavaScript 基礎設施時代的轉折點。從今天開始，效能、確定性、可預測性會比「跟 JS 共享 runtime」更重要。