Nestia：用純 TypeScript 型別同時產生驗證器、SDK 與 Swagger 的 NestJS 工具鏈

NestJS 型別與執行期之間那道裂縫

NestJS 的 DTO 在編譯後就消失了。TypeScript 的 interface 不會留下任何執行期資訊，所以驗證要靠 class-validator 的裝飾器、序列化要靠 class-transformer、文件要靠 @nestjs/swagger 的裝飾器，客戶端型別則往往再手寫一份。同一個欄位因此被描述四次，改一次就要同步四處。Nestia 針對的就是這個重複。README 開頭寫得很直白，它是一組 NestJS 的 helper libraries，並強調「Only one line required, with pure TypeScript type」。也就是說，DTO 只寫一次，其餘由工具從型別推導。它的目標讀者是已經在用 NestJS、前後端都是 TypeScript、且對 API 契約漂移有實際痛感的團隊。純 JavaScript 後端或非 TypeScript 客戶端拿不到主要好處。

從 DTO 型別長出驗證器、SDK 與 Swagger 的路徑

Nestia 不是執行期框架，而是一組在 build 階段運作的工具。專案被拆成幾個套件：@nestia/core 提供控制器裝飾器，README 列出 @TypedRoute、@TypedBody、@TypedParam、@TypedQuery、@TypedFormData、@TypedHeaders、@TypedException 與 @WebSocketRoute；@nestia/sdk 負責產生 Swagger 文件、客戶端 SDK、Mockup Simulator 與 E2E 測試函式；@nestia/e2e 與 @nestia/benchmark 分別是跑測試與跑效能的執行器；@nestia/editor 是帶線上 TypeScript 編輯器的 Swagger-UI。資料流大致是：控制器上的 @TypedBody 之類裝飾器標記了參數型別，nestia 的 CLI 讀取這些型別，產生對應的驗證程式碼與客戶端函式。README 把產出的 SDK 描述為「Collection of typed fetch functions with DTO structures like tRPC」，並說 Mockup Simulator 類似 msw 但全自動。需要說清楚的是，驗證器與 SDK 都是產生出來的程式碼，型別推導發生在編譯期，不是執行期反射。這也解釋了為什麼它能宣稱比 class-validator 快很多：比較的基準是裝飾器中繼資料的執行期檢查，對上直接產生的檢查函式。README 給出的數字是 runtime validator 比 class-validator 快 20,000 倍、JSON 序列化比 class-transformer 快 200 倍、整體效能提升 30 倍。這些是專案自己的宣稱，README 也連到 benchmark/results 目錄下的結果，我沒有重跑，數字請當作待驗證的參考值。

安裝與產生流程的實際指令

README 沒有把安裝步驟攤在首頁，而是指向 nestia.io/docs/setup。能從素材確認的是 CLI 名稱：套件列表最後一項寫著「nestia: Just CLI (command line interface) tool」，也就是說產生動作由 nestia 這支 CLI 驅動。設定檔方面，素材提到的是 nestia.config.ts 這個檔名，用於描述輸入與輸出，但具體的 key 名稱與完整範例不在提供的材料中，請以官網 Setup 頁面為準。可以確定的是幾個進入點：@nestia/core 的裝飾器從套件匯入後直接掛在控制器方法與參數上，@nestia/sdk 產生 SDK 與 Swagger，@nestia/e2e 則提供測試程式的執行方式，文件路徑在 nestia.io/docs/e2e/development。由於驗證器與 SDK 是產生檔，實務上會把產生指令放進 package.json 的 scripts，讓 build 或 CI 每次重跑。這一點素材沒有直接給範例，我不補造指令內容。

產生式驗證換來的是建置期的硬約束

把驗證從執行期搬到編譯期，代價是整個鏈路對型別的靜態可分析性變得敏感。型別必須能在編譯期被完整解析，凡是靠執行期才知道形狀的 DTO，例如從資料庫 schema 動態組出的欄位、或由外部設定檔決定的聯合型別，都可能落在工具能處理的範圍之外。第二個約束是 build 順序：控制器改了型別，SDK 與 Swagger 不會自己更新，必須重跑產生流程，否則前端拿到的 SDK 與後端實際行為不一致，而這種不一致在型別層面看不出來。第三是產生檔的處置。素材提到 SDK 有 Distribution 一章，說明產出的 SDK 可以獨立發布，但沒有交代產生檔是否該進版控、衝突怎麼解，這在多人協作時是會反覆出現的決策。最後，Nestia 與 NestJS 的版本是綁在一起的，v13 系列在 2026 年 8 月連續發布 v13.0.0、v13.0.1、v13.0.2，三個版本集中在三週內，主版號跳動意味著升級時要預期產生結果或設定格式有變動。

什麼情況下不該用它

如果 API 是對外的公開介面，且客戶端不限於 TypeScript，Nestia 的 SDK 產生器幫不上忙，你仍然需要一份語言無關的規格，而那份規格得另外維護，重複並沒有消失。如果團隊已經用 GraphQL 或 gRPC 定義契約，型別來源本來就是 schema，再引入一層 TypeScript 型別推導只是多一個步驟。如果專案規模很小、控制器不到十個，手寫 class-validator 裝飾器的成本低於設定產生流程與處理產生檔的成本。反過來說，當 DTO 數量成長、前後端由不同人維護、且每次欄位調整都會造成前後端不同步時，Nestia 的價值才真正出現。它不是效能優化工具，雖然 README 主打效能數字；它真正的賣點是消除契約的重複描述。

與 tRPC 的差異在哪裡

README 自己把 SDK 比作 tRPC，這個類比值得拆開看。tRPC 要求客戶端直接呼叫伺服器的 router 型別，前後端共用同一份 TypeScript 專案或至少共用型別套件，走的是 RPC 風格的呼叫路徑。Nestia 走的是 REST：伺服器仍然是標準的 NestJS 控制器與 HTTP 路由，SDK 是產生出來的 fetch 函式集合，客戶端透過這些函式打一般的 HTTP 端點。差別在耦合程度。tRPC 的客戶端與伺服器型別是即時連動的，改一個 procedure 簽章，客戶端立刻編譯失敗；Nestia 的 SDK 是產生檔，中間隔了一次產生步驟，型別不會自動跟著控制器走，但換來的是端點仍是普通 REST，可以被非 TypeScript 的呼叫者、curl 或第三方整合使用。如果你的客戶端只有自家前端，tRPC 的即時回饋更直接；如果你需要保留 REST 介面同時想要型別化客戶端，Nestia 的取捨更合理。另一個選項是 OpenAPI 產生器加 openapi-typescript 這類工具，差別在於契約的源頭是裝飾器中繼資料還是 TypeScript 型別本身。

維護成本與授權

Nestia 以 MIT 授權發布，README 的 badge 與 LICENSE 連結都指向 MIT。MIT 允許商業使用、修改與再散布，實務上要注意的是產生出來的 SDK 屬於你的專案還是被視為衍生作品，這取決於產生檔中是否包含 Nestia 的執行期程式碼，@nestia/fetcher 是作為依賴被 SDK 引用的，這部分請自行確認授權標示需求，本文不提供法律意見。維護面有兩項具體成本。第一是版本綁定：Nestia 的裝飾器與 NestJS 的控制器生命週期緊密相連，NestJS 升主版時 Nestia 通常需要跟著升，從 v13.0.0 到 v13.0.2 的密集發布節奏來看，小版之間也可能有行為調整。第二是產生流程的執行時間與 CI 設定，每次 build 都要跑一次 CLI，這在大型專案上不是零成本。素材中沒有提供升級指南或破壞性變更清單，所以升級前應該先讀 release notes，並在分支上重跑產生流程比對輸出差異。

編輯結論

如果你的 NestJS 後端與前端共用 TypeScript，且願意在 build 流程中加入 nestia 的程式碼產生步驟，Nestia 能讓 DTO 型別成為驗證、SDK 與 Swagger 的共同來源，省下三份手寫維護。若你的控制器大量依賴動態 schema、執行期才決定的 DTO，或團隊不接受產生檔進版控，它會變成阻力而非助力。導入前先確認三件事：nestia.config.ts 的 input 與 output 路徑是否符合你的目錄結構、@nestia/core 是否與你目前的 NestJS 主版本相容、以及 CI 是否能在每次 build 重跑產生流程。先在其中一個模組試，不要一次改整個後端。

官方來源

1. License: MIT
2. Project website
3. README
4. Releases
5. samchon/nestia on GitHub