Bun 內建 bun check，型別檢查比 tsc 7 快 3 至 6.4 倍
Bun 官方部落格 · 2026-10-10
TypeScript 專案的型別檢查，原本得另裝 typescript 套件再跑 tsc --noEmit，現在 Bun 自帶一個同樣讀 tsconfig.json 的 bun check 取代它。這是 Bun v1.4.3 的主打功能，由 Jarred Sumner 於 2026-10-10 發布。
它是 typescript-go 的移植版，只做型別檢查，不輸出 JavaScript 或 .d.ts，也沒有 language server，編輯器仍然用 TypeScript 本身。
原本的問題
CI 裡的型別檢查常是整條流程最慢、最吃記憶體的一步。大型 monorepo 的 tsc 要把整個程式圖載入記憶體，依官方表格，VS Code 的 src（9,795 個檔案）用 tsc 7.0.2 要 5.98 秒、7.97 GB。
另一個繞路是型別檢查和執行分離：用 Bun 跑程式時不會檢查型別，所以多數人在 package.json 另寫一個 tsc 腳本，或乾脆讓型別錯誤進到 runtime。
核心改動
bun check 會用到所有 CPU 核心，不需要安裝 typescript，並宣稱通過 TypeScript 7.0.2 conformance suite 的 51,210 個 baseline 測試中的 51,210 個。以下數字來自 16 核心 Apple silicon Mac 上的對照表：
| 專案 | 檔案數 | bun check | tsc 7.0.2 | 倍率 |
|---|---|---|---|---|
VS Code src | 9,795 | 1.24 s | 5.98 s | 4.8x |
| mikro-orm | 2,883 | 1.20 s | 5.97 s | 5.0x |
Next.js packages/next | 2,881 | 0.28 s | 1.82 s | 6.4x |
| Nuxt | 839 | 0.27 s | 0.80 s | 3.0x |
記憶體也少：VS Code src 為 2.14 GB 對 7.97 GB（3.7x），mikro-orm 為 1.35 GB 對 6.67 GB（4.9x）。另一組 Linux x64、64 執行緒、10,947 個檔案的測試中，bun check 為 1.75 秒，tsc 7 加 --checkers 16 為 5.88 秒，預設設定則是 12.58 秒。官方註明這組檔案數與上表不同，兩者不能直接比較。
它同時接進了 Bun 其他指令，錯誤時都會中止：
bun run --check <file>：先檢查再執行，也支援package.json腳本與--watch。bun test --check：先檢查測試檔與其匯入的檔案。bun build --check：型別錯誤時整個 build 失敗，不寫出任何檔案。Bun.build接受check: true。
影響範圍
CI 裡只跑 tsc --noEmit 的專案最直接受益：可以把那一步換成 bun check，省下安裝 typescript 的時間，也降低 runner 的記憶體需求。但如果你的專案依賴 tsc 產生 .d.ts（發布函式庫），仍然需要 tsc，因為 bun check 不 emit。
換之前先自己對照結果，不要只信官方數字。官方給的驗證方式如下，並表示任何差異都視為 bug：
bunx -p typescript@7.0.2 tsc --noEmit --pretty false > tsc.txt
bun check --no-pretty > bun.txt
diff tsc.txt bun.txt一致性並非完美。官方自己列出的差異包括：72 個專案的比對中有 1 個不一致（vuejs/core，只有在 files 中 global.ts 排在 model.ts 之前時 tsc 才會回報）；關閉 strict 時，69 個專案共 76,960 個錯誤中有 12 個不一致；fuzzer 在 3,032,182 個程式中找到 191 個不一致，其中 162 個涉及宣告時引用自身的程式碼。
另外，bun check 沒有 language server，所以它取代的是 CI 與 pre-commit，不是編輯器內的即時檢查。release notes 未說明是否支援 project references 與增量建置，採用前請先在自己的 tsconfig.json 上試跑。
怎麼接進現有流程
最低成本的做法是先並行：保留原本的 tsc 步驟，另外加一個 bun check 步驟，連續幾天比對輸出，沒有差異再移除舊步驟。這樣即使遇到上述的少數不一致，也不會讓 CI 誤放行有問題的型別。
如果你本來就用 Bun 跑測試或打包，bun test --check 與 bun build --check 可以直接取代「先 tsc 再 test」的兩段式腳本，型別錯誤會在同一個指令內中止，不必再維護額外的 npm script。官方的速度數字都是在高核心數機器上量的，跑在 2 到 4 核心的 CI runner 上，倍率可能明顯較低，文章中未提供這類環境的數據。
要注意的是，bun check 對齊的是 TypeScript 7.0.2 的行為。如果專案鎖在更舊的 TypeScript 版本，兩邊對新語法或新檢查規則的判斷可能不同，先確認團隊使用的版本再決定是否切換。
同版其他值得注意的改動
同一版還有 node:http 大型回應最高快 2.7x，以及 Promise.allSettled 在 100,000 次拋錯的非同步呼叫下由 24 秒降到 148 毫秒。此外，--disallow-code-generation-from-strings 現在會擋下 eval() 與 new Function()，依賴動態程式碼生成的套件在啟用該旗標前要先檢查。