NestJS 12 大版本轉向 ESM：新專案預設構建改用 Rspack 的工程變化回顧

截至 2026 年 9 月 2 日，npm 上 @nestjs/core 的 latest 版本已經是 12.0.1。掘金一篇於 9 月 4 日刊出的長文，以這個版本狀態為切入點，整理了 NestJS 12 這條大版本線的主要變化。本臺以回顧角度，綜合該文內容與 npm 公開版本資訊，梳理這輪 Major Release 的輪廓。需要先說明的是，12.0.0 是 v12 首個正式版本，討論升級重點時，核心在於整條大版本線帶來的工程層面調整，12.0.0 與 12.0.1 之間的差異屬於次要修訂。

核心套件轉向 ESM，但不強迫應用跟著遷移

NestJS 12 最基礎的變動，是核心套件開始以 ESM 形式發布。目前 @nestjs/core 的 package.json 已宣告 type 為 module。掘金文章特別指出這裡最容易產生的誤解：框架套件變成 ESM，不代表現有應用必須立刻從 CommonJS 遷移過去。

技術上，較新的 Node.js 版本已能在 CommonJS 環境中透過 require(esm) 載入符合條件的 ESM 套件。因此從 NestJS 11 升級到 12 時，專案可以先保留原本的 module: commonjs 設定。官方新增的 nest upgrade 指令也不會擅自把專案改成 ESM，遷移指南明確將應用自身的 ESM 遷移列為可選步驟。

這個取捨的意義在於拆分風險。如果一次大版本升級同時強迫開發者完成 Node.js 版本升級、CommonJS 遷 ESM、測試框架遷移、構建工具更換等多項工程，採用阻力會大幅提高。掘金文章的判斷是，NestJS 12 應被視為一次工程基礎設施升級，而非普通的依賴版本更新。

Standard Schema 貫穿驗證、序列化與設定校驗

資料驗證層是另一條主線。NestJS 12 原生支援 Standard Schema 規範，Zod、Valibot、ArkType 這類工具產生的 Schema 可以直接進入框架的驗證體系。與之配套的是新增的 StandardSchemaSerializerInterceptor，讓請求與回應可以共用同一套 Schema-first 的思路。

設定校驗方面，@nestjs/config 也接入 Standard Schema。掘金文章指出，新專案不必再圍繞 Joi 設計設定驗證，但既有使用 Joi 的專案仍可繼續運作，兩者並行不衝突。

CLI 與構建工具：Rspack、Vitest、oxlint 成為新預設方向

新專案範本是這輪更新中對日常開發影響最直接的部分。CLI 生成的專案進一步轉向 Rspack 作為構建工具，Webpack 專屬參數進入棄用階段；測試框架預設採用 Vitest；Lint 工具預設生成 oxlint。官方並未要求既有專案同步遷移測試與 Lint 配置，掘金文章也提醒老專案可按自身節奏處理。

CLI 另一方面新增了 nest upgrade 與 nest deploy 指令。前者用於處理大版本升級，能自動完成一部分機械性遷移工作；後者則對應部署環節。

生產診斷能力補齊：路由、錯誤碼、結構化日誌與可觀測性

框架正式邊界內也納入了多項過去需要應用自行補齊的工程能力。官方新增 @nestjs/observe 可觀測套件，涵蓋 Controller、Resolver、Queue Consumer、Cron 等生命週期。路由層新增衝突診斷與 Specificity 排序，Express 專案可以提前發現動態路由遮擋靜態路由的問題。HttpExceptionOptions 開始支援 errorCode，客戶端可以依賴穩定的錯誤碼，不必解析錯誤文案。日誌方面，普通物件參數預設成為 Structured Params，掘金文章提醒，既有的日誌採集、告警與儀表板流程可能受到影響，需要檢查。

GraphQL 與 NATS 的破壞性變更

兩項變更涉及具體的協議與驅動更換。GraphQL 端 GraphiQL 成為新的預設介面，舊的訂閱協議被移除，使用 Subscription 的專案需要檢查客戶端協議相容性。NATS Transporter 則切換到 NATS v3 Driver，自訂的 Serializer 與 Deserializer 需要回歸測試。這兩項屬於升級時必須逐一排查的破壞性變更，與前述可選遷移形成對照。

訊源與可核實邊界

本篇整理主要依據掘金作者 Moment 於 2026 年 9 月 4 日刊出的長文，其中版本狀態以 9 月 2 日的 npm 資料為準，兩個日期之間若仍有修訂版發布，不在該文涵蓋範圍。文中有關 @nestjs/core 的 package.json 設定、CLI 指令行為與各項預設值，均可透過 npm 套件頁面與官方遷移指南交叉核對。掘金文章本身帶有作者的升級建議立場，例如建議將 v12 視為工程基礎設施升級，這部分屬於個人判斷，本臺如實轉述，不做評斷。讀者若規劃實際升級，應以 NestJS 官方遷移指南與變更日誌為最終依據。