每日突破性工具推薦｜scriptc

scriptc：把普通 TypeScript 編譯成原生程式

工具定位與適用情境

scriptc 是 Vercel Labs 開源、目前仍屬實驗階段的 TypeScript-to-Native Compiler。它直接接受一般 TypeScript / JavaScript，使用官方 TypeScript compiler 進行 parsing 與 type checking，再將可靜態編譯的程式轉換為 typed IR，並可輸出 readable C、LLVM IR、assembly、object、native executable 或 WebAssembly。

它特別適合 CLI、短生命週期工具、需要降低啟動成本的服務，以及希望以 TypeScript 開發、但不想在部署端攜帶 Node.js / V8 的程式。

為什麼今天推薦它

scriptc 並不是單純把 Node.js 打包進 executable，而是在嘗試回答更激進的問題：

TypeScript 程式中，究竟有多少部分其實可以在編譯期確定，並直接變成原生機器碼？

這使它和 Bun compile、Deno compile、Node SEA 等「把 JavaScript Runtime 與應用一起封裝」的方向有本質差異。scriptc 的靜態模式產物只攜帶小型 native runtime，不包含 Node 或 JavaScript engine。

專案目前約有 4.9k GitHub stars、675 次 commits，仍有大量 Pull Requests 與近期開發活動；因此本次採用「近期快速成長且具代表性工具」的 fallback，而不是把它描述成已成熟的 Production Compiler。

突破性重點：Staticness 是顯式契約

scriptc 最有價值的設計不是「TypeScript 可以變成 native binary」本身，而是它沒有假裝 JavaScript 的所有動態語意都能被可靠 AOT 編譯。

它把程式分成三種情況：

Static：可以確定型別與行為的程式直接編譯成 native code。
Dynamic：使用 --dynamic 時，無法靜態化的 npm JavaScript 或 any 程式可交給內嵌 quickjs-ng 執行。
Rejected：無法安全處理的程式直接產生 diagnostic，而不是默默產生可能錯誤的 native code。

scriptc coverage 則能分析程式中多少 statements 可以靜態編譯，並列出阻止 native compilation 的具體位置。

這讓「可靜態化程度」變成開發者可以量測、改善與納入 CI 的工程指標。

核心架構與運作方式

典型 pipeline 可以概括為：

text

TypeScript / JavaScript
        ↓
TypeScript Parser + Type Checker
        ↓
Typed Intermediate Representation
        ↓
 ┌──────┴───────────────┐
 │                      │
Static Region      Dynamic Region
 │                      │
LLVM / Native       quickjs-ng
 │                      │
 └──────────┬───────────┘
            ↓
 Small Native Runtime
            ↓
Native Executable / WASM

目前 compiler 可以直接產生 typed IR、C、LLVM IR、assembly 與 relocatable object；一般 LLVM-tier executable 則使用 bundled helper 與 precompiled runtime pack。最終 executable 不需要 Node.js。

值得注意的是，scriptc 並非完全「zero runtime」：靜態 binary 仍包含它自己的小型 native runtime。更精確的說法應是 zero JavaScript-engine / zero Node runtime dependency。

Node API 相容策略

scriptc 不只處理純計算 TypeScript，也逐步實作 Node API 的 native runtime 對應。例如官方 README 已展示 node:http server 可直接編譯成 native executable。

這條路線的重要性在於：如果只支援語言語法而不支援實際 Node API，compiler 很容易只能處理 benchmark 或演算法範例；Node compatibility 才決定它是否有機會承接真實 TypeScript workload。

目前仍必須逐項確認 API coverage，不能假設現有 Node.js 專案可以無修改完整編譯。

WebAssembly 與跨平台

scriptc 目前目標涵蓋 macOS、Linux、Windows，以及 WASI Preview 1。

WASI target 可以支援 async/await、Promise、generator、timer、stdin/readline 與部分 filesystem API；但 portable WASI Preview 1 沒有的 capability，例如 network sockets、fetch、child process、OS signals 與 filesystem watching，會在 linking 前直接產生 diagnostic。

這種「在 build time 明確拒絕平台不可能支援的能力」比部署後才發生 runtime failure 更容易治理。

主要優勢

1. TypeScript 不再必然等於 JavaScript Runtime

對能完全靜態化的程式，部署產物可以不攜帶 Node、V8 或其他 JavaScript engine。這對 CLI、工具程式與大量短生命週期 process 特別有意義。

2. 保留真正的 TypeScript Frontend

scriptc 使用 TypeScript compiler 做 parsing 與 type checking，而不是重新發明一套「長得像 TypeScript」的語言，因此能最大程度保留既有 TypeScript 開發體驗。

3. 靜態與動態可以混合

--dynamic 允許必要時內嵌 quickjs-ng，讓專案不必在「100% native」與「完全不能編譯」之間二選一。

跨越 static / dynamic boundary 的值會進行 runtime validation，降低錯誤型別直接破壞 native memory 的風險。

4. Compiler artifact 非常透明

能直接查看 typed IR、C、LLVM IR、assembly 與 object，使 scriptc 不只是一個 bundler，也能成為研究 TypeScript AOT compilation 與 native interoperability 的工具。

5. Differential Testing 思路正確

專案測試會讓同一 corpus 分別在 Node 與 compiled native binary 執行，再比較 stdout、stderr 與 exit code。對試圖重現 JavaScript / Node 語意的 compiler 而言，這種 differential testing 是很重要的 correctness strategy。

與同類工具的差異

工具方向	典型做法	scriptc 的差異
Node.js	V8 + Node runtime 執行 JS	可靜態化程式直接轉 native code
Bun	高效 JavaScript runtime	scriptc 靜態產物不需要 JS engine
Deno	Runtime + compile/distribution 能力	scriptc 更強調 AOT staticness
Node SEA	將 Node app 封裝成 executable	scriptc 不是把完整 Node runtime 當主要執行模型
QuickJS bundling	小型 JS engine 執行 JS	quickjs-ng 在 scriptc 是明確 opt-in 的 dynamic tier
Rust / Go	原生語言直接 AOT	scriptc 保留 TypeScript 語言與部分 Node 生態相容性

因此它真正競爭的並不只是 JavaScript Runtime，而是「TypeScript 是否能逐步成為 native application language」這個更大的設計空間。

缺點與限制

首先，scriptc 官方明確標示為 experimental。目前不應把它當作 Node.js 的 production drop-in replacement。

其次，JavaScript 的高度動態特性本來就與 AOT compilation 衝突。大量依賴 any、runtime reflection、monkey patching 或高度動態 npm package 的程式，會降低 static coverage，甚至必須進入 dynamic tier。

第三，Node API compatibility 仍是長期工程。即使 TypeScript 語法可以編譯，也不代表所有 Node package 與 native addon 都能直接使用。

第四，WASI Preview 1 本身的 capability boundary 仍會限制 networking、process 與 OS integration。

最後，compiler 本身目前仍需要 Node.js 24+；「不需要 Node」指的是 編譯後的 executable，不是 build toolchain。

適合的使用者與專案

scriptc 特別值得以下專案評估：

TypeScript CLI 與 developer tools
希望交付單一 native executable 的工具
對 process startup 與 deployment footprint 敏感的 workload
TypeScript + native C ABI / FFI 整合
Compiler、AOT、WASM 與 Runtime 研究
願意針對 static coverage 調整程式設計的新專案

不適合的情境

目前不建議直接用於：

必須高度相容完整 Node.js 生態的既有大型系統
大量使用動態 JavaScript metaprogramming 的專案
無法接受 experimental compiler 風險的核心 Production Service
依賴大量未驗證 native addons 的應用
團隊只想「build 一次就完全相容 Node」而不願處理 static coverage 的專案

結論

scriptc 最值得注意的不是「把 TypeScript 變快」這個表層敘事，而是它正在測試一個更根本的架構假設：

TypeScript 是否一定要與大型 JavaScript Runtime 綁在一起？

它用 typed IR、顯式 static coverage、LLVM native backend、小型 native runtime，以及可選的 QuickJS dynamic island，把 TypeScript 從純粹的 JavaScript 開發語言往 AOT/native application language 推進。

現在它還太早期，不適合取代 Node.js 成為一般 Production Runtime；但對 CLI、Developer Tool、Serverless 冷啟動、WASM 與 native TypeScript 研究而言，它已經是一個非常值得追蹤的方向。

如果這套模型持續成熟，未來 TypeScript 生態可能不再只有「選 Node、Bun 或 Deno」這種 Runtime 選擇，而會多出另一條路：在可以證明程式足夠靜態時，乾脆不帶 JavaScript engine。