TypeScript 7.0 編譯速度提升10倍——Vue、Svelte 和 Angular 需等待 7.1 版本

過去，VS Code 內建的 TypeScript 編譯器在檢查編輯器自身程式碼庫的全新副本時，需要耗費 125 秒。TypeScript 7.0 完成同樣的工作只需 10.6 秒。微軟並非對舊程式碼進行最佳化，而是將整個編譯器執行環境從 JavaScript 移植到 Go，從而實現了 JavaScript 引擎無法提供的多核心平行運算能力。

這次移植並非從零開始重寫。微軟的工程師表示，型別檢查邏輯在結構上與 TypeScript 6.0 完全相同——同樣的規則、同樣的行為，只是轉換到一種能將工作分散到多個 CPU 核心的語言。團隊選擇 Go，是因為原本以函式為主的 JavaScript 程式碼幾乎可以一對一地對應到 Go 的慣用寫法。新的執行環境也引入了明確控制平行運算的旗標：在現代工作站上傳遞 –checkers 8 參數，能讓 VS Code 的建置速度比 TypeScript 6.0 提升 16.7 倍。Slack 的 CI 型別檢查時間從 7.5 分鐘降至 1.25 分鐘。Bluesky 的建置時間從 24.3 秒降至 2.8 秒。這個模式在各個程式碼庫中皆然：隨著專案規模增長，效能提升的幅度會更加顯著，因為瓶頸現在取決於硬體，而非執行環境。

TypeScript 7.0 並未提供公開的程式化 API——也就是建置工具在自身程式碼中呼叫編譯器時所使用的介面。每個主要網頁框架的模板型別檢查器都依賴於此。Vue 的 Volar 工具、Svelte 的語言服務、MDX、Angular 的模板檢查器：它們都無法在 TypeScript 7.0 上運作。像 ts-morph 和 ts-jest 這類會暴露 TypeScript 編譯器內部結構以進行重構和測試的工具，也同樣無法使用。微軟已確認，替代 API 預計在 TypeScript 7.1 中推出，時程約在 10 月。使用上述任何框架或工具的專案，目前還不應升級。

較舊的專案配置則會面臨另一組硬性障礙。TypeScript 7.0 將 6.0 版已棄用的選項直接變成建置錯誤：ES5 編譯目標、AMD 和 SystemJS 模組格式、classic 模組解析方式，以及 import 陳述式上的 assert 關鍵字，都會直接導致建置失敗。新的預設 tsconfig.json 不再自動載入 @types 套件，這意味著依賴於環境型別自動發現、卻未明確宣告型別依賴的專案，在匯入時會靜默失敗。微軟提供了一個 typescript@npm:@typescript/typescript6 相容性墊片，讓需要讓 TS6 工具與新編譯器並行的專案可以使用。

能夠跨越這些障礙的專案——純 Node.js 或 Deno 應用程式、非基於框架模板系統的瀏覽器應用程式，以及不依賴程式化 API 的函式庫——只需修改 package.json 中的一個設定即可升級。編輯器支援也遵循同樣的分裂：VS Code 現在已有專用的 TypeScript 7 擴充功能可用，而內建的支援正在遷移至語言伺服器協定 (Language Server Protocol)，取代舊的 TSServer 設計。同樣依賴 TSServer 的 WebStorm 及其他編輯器，仍在處理這項轉換。

TypeScript 7.1 目前預計於 2026 年 10 月推出，屆時將提供 Vue、Svelte、Angular 和 MDX 工具在遷移前所需的新編譯器 API。當它到來時，這項耗時 15 個月的 Go 移植所帶來的效能提升，將能惠及整個生態系統。在此之前，Volar、SvelteKit 和 Angular 的專案頁面都建議停留在 TypeScript 6.0.x 版本。

標籤: 微軟, Go, TypeScript, 程式設計