NestJS 12：ESM 包、标准模式验证和原生可观测性

用于构建服务器端 Node.js 应用程序的 TypeScript 框架 NestJS 发布了 12 版本。这个大版本将核心包迁移至 ESM，新增了作为一等公民的 Standard Schema 验证功能，重构了 CLI，并推出了官方可观测性 SDK。该版本符合 4 月份公布的路线图，其创建者 Kamil Myśliwiec 在 X 平台发布的公告已获得超过 1100 个赞和 6.6 万次浏览。

迁移到 ESM 成为头条新闻，这很大程度上是因为它对现有团队的要求极低。现在，核心包以 ESM 格式发布，但借助 Node.js 对 require(esm) 的支持， CommonJS 应用程序仍然可以继续运行，这也是 v12 要求使用 Node.js 20.19+ 或 22.12+ 的原因。现在，运行 nest new 时会询问是生成 CJS 还是 ESM 项目，其中 ESM 项目默认使用 Vitest 和 oxlint，而 Rspack 已经取代 webpack 成为单仓库打包器。开发者 Anton Chapala 在预览版基准测试中发现，ESM 在启动速度或内存占用方面并未带来显著的提升。他总结道，该版本“是对工具链和配置债务的一次大规模清理”，而非性能方面的升级。

就日常的人机工程学实践而言，验证方面的变化最大。诸如 @Body()、@Query() 和 @Param() 之类的路由装饰器支持 schema 选项，可以接受任何与标准模式（Standard Schema）兼容的对象。因此，一旦注册了新的管道，Zod、Valibot 和 ArkType 就可以在无需第三方封装的情况下正常工作。

class-validator 仍然是文档中记录的默认选项。博主 iiaku 认为，基于规范而非直接基于 Zod 进行开发“既能保留选择权，又能消除冗余代码”。不过，在 ByteIota 的预览报道下面，有评论者指出，由于 Nest 仍然依赖于旧版 TypeScript 装饰器，所以类型仍然需要手动注解。

在新增的功能中，争议最大的是 @nestjs/observe。它通过一个新增的 instrument 选项挂接到 Nest 自身的生命周期中而非对 HTTP 服务器进行修补，并以控制器和提供者为单位报告跟踪信息。APM 供应商 Scout Monitoring 承认，该功能提供了更丰富的上下文信息，但同时也警告称，该 SDK“仅限 NestJS”，未提供开箱即用的跨栈关联功能，而且“在框架层面存在陷入供应商锁定”的风险。一个新增的 nest deploy 命令（转发至 Mau 平台）也同样指向了第一方服务。

从 v11 升级意味着需要通过 npm i -g @nestjs/cli@latest 安装最新的 CLI，并运行 nest upgrade 命令。该操作会将所有的 @nestjs/* 包升级至 v12，将 TypeScript 升级至 v6，并应用一些技术性变更，例如将 GraphQL Playground 切换为 GraphiQL，以及替换为 NATS v3 客户端。

该操作刻意没有将项目转换为 ESM、Vitest 或 oxlint。要了解其余内容，包括生命周期钩子的顺序以及 Joi v18，请查阅迁移指南。

一个 GitHub 问题驱动文档指出，AWS Lambda 运行时需要 --experimental-require-module 参数，而其他用户则报告称，在 ESM 环境下路径别名无法正常工作，而且 Fastify 中间件会异常卡死。随后的 v12.1 版本已经新增了内置的 Cookie、CSRF 保护和安全响应头。

NestJS 是一个采用 MIT 许可的开源框架，用于使用 TypeScript 构建高效且可扩展的服务器端应用程序。它结合了受 Angular 启发的模块和依赖注入架构，并支持 Express 和 Fastify，在 GitHub 上拥有超过 7.6 万个星标。

原文链接：https://www.infoq.com/news/2026/10/nestjs-12-observability/