TypeScript 7.0 的重點不是新語法，而是工具鏈換心臟#

TypeScript 7.0 的官方公告把它稱為 10x faster native port。它不是在原本 JavaScript 版本上做局部最佳化，而是把 TypeScript 工具鏈用 Go 重新實作，目標是保留既有編譯器邏輯與相容性，同時讓工具可以吃到原生程式、多執行緒與共享記憶體帶來的效能。

官方列出的測試資料中，幾個大型開源專案的完整建置時間有明顯下降：

這些數字不能直接套到每個專案，但方向很明確：TypeScript 7.0 不是只讓 tsc 快一點，它也會影響每天開發時的回饋速度，例如打開專案、跳到定義、找 references、自動完成、即時診斷、--watch 等。

對我來說，真正有感的可能不是「CI 少幾十秒」，而是大型專案中編輯器不再卡到讓人想關掉型別檢查。型別系統如果太慢，團隊最後會把很多檢查往 CI 推；但 CI 才報錯時，修正成本就已經變高了。

安裝方式看似一樣，但 API 還沒準備好#

官方目前的安裝方式仍然是：

1
npm install -D typescript

安裝後會取得新的 tsc。如果只看 CLI，這很直覺；但 TypeScript 7.0 有一個升級時最需要注意的限制：它目前沒有提供穩定的程式化 API。

這會影響哪些工具？大致是那些會把 TypeScript 當函式庫嵌入使用的工具，例如：

• typescript-eslint
• Vue 的 Volar 相關工具鏈
• Astro / Svelte / MDX 這類需要處理嵌入式語言的語言服務
• 其他依賴 TypeScript compiler API 的分析、轉換或檢查工具

官方提供的過渡方案是 @typescript/typescript6，讓 TypeScript 6 的 API 可以與 TypeScript 7 的 tsc 並存。若工具仍需要從 typescript 匯入舊 API，可以透過 npm alias 讓 typescript 指向 TypeScript 6 相容套件，再另外安裝 TypeScript 7：

1
{
2
  "devDependencies": {
3
    "@typescript/native": "npm:typescript@^7.0.2",
4
    "typescript": "npm:@typescript/typescript6@^6.0.2"
5
  }
6
}

這段設定的意思是：typescript 這個套件名仍提供 TypeScript 6 API 給既有工具使用，而 TypeScript 7 另外用 alias 安裝。實務上要怎麼接進 npm scripts，需要看專案目前怎麼跑 tsc、eslint、框架檢查與 CI。

Vue、Astro、Svelte 專案先不要只看 tsc 成功#

這次公告中特別點名：Vue、MDX、Astro、Svelte 等工作流，目前很可能還不能完整使用 TypeScript 7。原因不是這些框架不重要，而是它們常常把 TypeScript 嵌進自己的 compiler 或 language service；TypeScript 7.0 還沒有穩定 API，所以相關工具暫時只能依賴 TypeScript 6.0。

這也是我覺得前端專案升級時最容易誤判的地方。

如果你的專案是純 TypeScript CLI 檢查，TypeScript 7.0 可能很快就能帶來回饋速度改善。但如果你的專案是 Vue、Astro 或 Svelte，不能只跑：

1
npx tsc --noEmit

就判斷「升級完成」。你還需要確認：

• 編輯器語言服務是否仍正常顯示 template / component 內的型別錯誤
• vue-tsc、astro check、svelte-check 是否支援目前的 TypeScript 版本配置
• ESLint 與 typescript-eslint 是否需要 TypeScript 6 API
• CI 中跑的是 TypeScript 7 的 tsc，還是框架自己的檢查命令

以這個部落格專案來說，目前是 Astro + Svelte，package.json 仍使用 TypeScript 5.x，檢查命令是 astro check。如果要試 TypeScript 7，我不會直接把 typescript 拉到 7 後就推上正式分支，而會先在獨立分支確認 astro check、編輯器提示、Svelte 元件型別與 build 都沒有被工具鏈相容性卡住。

新的平行化選項：快，但不是越大越好#

TypeScript 7.0 導入更多平行化處理，包含 parsing、type-checking、emitting，以及 project reference build。它也新增幾個可以調整平行化行為的旗標：

1
tsc --checkers 4
2
tsc --build --builders 2
3
tsc --singleThreaded

--checkers 控制 type-checker workers 數量，預設是 4。官方資料中，把某些大型專案改成 --checkers 8 後，建置時間還能再下降。不過這不是無腦調大就好，因為更多 worker 也可能增加記憶體使用量。

--builders 則是針對 project references，允許多個 project 同時 build。這對 monorepo 比較有感，但要注意它會和 --checkers 相乘。例如 --checkers 4 --builders 4 代表最多可能同時有 16 個 type-checkers 在跑；在小型 CI runner 上，這種設定可能反而把 CPU 與記憶體打滿。

我會用這個順序調整：

1. 先用預設值跑一次，記錄 tsc --build 或 CI 的時間與記憶體。
2. 大型專案再試 --checkers 8，不要一開始就把所有 worker 拉滿。
3. monorepo 再測 --builders，並注意它與 --checkers 的乘數效果。
4. 如果要比對 TypeScript 6 / 7 行為，或環境資源很有限，再用 --singleThreaded 做排除。

tsconfig 的預設值與棄用項目會讓舊專案冒錯#

TypeScript 7.0 目標上相容 TypeScript 6.0 的型別檢查與命令列行為，但它也採用 TypeScript 6.0 的新預設值，並把一些舊設定變成 hard error。

幾個我會優先檢查的設定：

1
{
2
  "compilerOptions": {
3
    "strict": true,
4
    "module": "esnext",
5
    "noUncheckedSideEffectImports": true,
6
    "rootDir": "./src",
7
    "types": ["node"]
8
  },
9
  "include": ["./src"]
10
}

其中 rootDir 與 types 比較容易讓舊專案感到突然。官方提到，rootDir 現在預設為 ./，如果你的 tsconfig.json 放在專案根目錄、實際 source 在 src，可能需要明確設定 rootDir: "./src" 來保留原本輸出結構。

types 現在預設為空陣列。如果專案依賴 Node、Jest、Mocha、Bun 這些全域型別，應該明確列出：

1
{
2
  "compilerOptions": {
3
    "types": ["node", "jest"]
4
  }
5
}

另外，一些舊設定在 TypeScript 7.0 中不再支援，例如：

• target: es5
• downlevelIteration
• moduleResolution: node / node10
• moduleResolution: classic
• module: amd、umd、systemjs、none
• baseUrl
• 把 esModuleInterop 或 allowSyntheticDefaultImports 設成 false

如果專案歷史很久，或從 Webpack / Vue 2 / 舊 Node 工具鏈一路升上來，這些設定很可能還躺在 tsconfig.json 裡。升級前先清掉，比在 CI 上看到一串 hard error 再回頭找原因輕鬆很多。

watch mode 重寫，對大型專案更值得測#

TypeScript 7.0 也重建了 --watch mode。官方說新的 watch 基礎來自 Parcel watcher 的 Go 移植版本，用來改善跨平台檔案監看與資源消耗。

這點對小專案不一定有感，但大型前端專案常見的痛點是：開發伺服器、框架 checker、測試 watcher、IDE language server 同時監看大量檔案，最後每個工具都在追 node_modules、generated files 或 monorepo package 變更。

如果你的專案現在開 tsc --watch 會吃很多 CPU，TypeScript 7.0 值得單獨測。但測的時候不要只看第一次啟動時間，也要看：

• 修改單一檔案後多久回報診斷
• 大量 git checkout 後 watcher 是否穩定
• macOS / Linux / CI container 表現是否一致
• 是否和框架自己的 watcher 重複做事

我會怎麼決定要不要升級#

如果是純 TypeScript library、Node.js 服務、或沒有複雜框架語言服務的專案，我會優先開一個分支測 TypeScript 7.0。檢查重點放在 tsc --noEmit、tsc --build、CI 時間、記憶體、以及 tsconfig 舊設定。

如果是 Vue、Astro、Svelte、Angular、MDX 這類專案，我會先把 TypeScript 7.0 當成「可以測 CLI，但不要急著替換整個開發體驗」的版本。尤其是編輯器語言服務與框架檢查工具，現在還需要等生態系補上 TypeScript 7 的 API 與整合。

比較務實的升級路線會是：

1. 先把專案升到 TypeScript 6.0 相容狀態，修掉 deprecated flags。
2. 確認 tsconfig 裡的 rootDir、types、module resolution 都是明確設定。
3. 在獨立分支測 TypeScript 7.0 的 tsc 與 CI。
4. 框架專案先保留 TypeScript 6 API 給工具鏈使用。
5. 等 TypeScript 7.1 或框架工具明確支援後，再正式切換整體工作流。

這次 TypeScript 7.0 的方向很明確：型別檢查不應該慢到讓人繞過它。只是對前端專案來說，TypeScript 從來不是單一套件，而是一整串工具鏈的共同依賴。升級時把 tsc、editor、eslint、framework checker 分開看，會比單純追版本安全很多。

常見問題#