NestJS 12迁移核心包至ESM并新增可观测性SDK

NestJS 12现已发布。该版本将核心包迁移到ESM，新增作为一等能力的Standard Schema验证，重做CLI，并推出官方可观测性SDK，整体对应此前公布的路线图。其创建者Kamil Myśliec在X平台发布的公告获得超过1100个赞和6.6万次浏览。

ESM迁移对现有项目的影响相对有限：依托Node.js对require(esm)的支持，CommonJS应用仍可运行，但Node.js版本需达到20.19+或22.12+。执行nest new时可选择CJS或ESM项目，后者默认采用Vitest和oxlint；单仓库打包器则由Rspack替代webpack。预览基准测试显示，ESM并未明显改善启动速度或内存占用，因此本次升级更像是对工具链和配置债务的集中清理，而非性能版本。

验证能力是日常开发中变化较大的部分。@Body()、@Query()和@Param()等路由装饰器新增schema选项，可接收任意兼容Standard Schema的对象。注册相应管道后，Zod、Valibot和ArkType无需第三方封装即可使用；class-validator仍是官方文档记录的默认方案。不过，由于框架仍依赖旧版TypeScript装饰器，类型注解在部分场景下仍需手动补充。

@nestjs/observe通过instrument选项接入Nest自身生命周期，而不是改造HTTP服务器，并可按控制器和提供者维度上报追踪信息。其上下文更丰富，但目前只面向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。实践中，AWS Lambda可能需要--experimental-require-module参数，部分用户还遇到ESM路径别名失效及Fastify中间件卡死问题；后续v12.1已加入内置Cookie、CSRF防护和安全响应头。

NestJS采用MIT许可证，是用于TypeScript服务器端应用开发的开源框架，提供受Angular启发的模块化与依赖注入架构，并兼容Express和Fastify。目前其GitHub项目已获得超过7.6万颗星标。