NestJS 12.0.0 成为首个正式版并指向 latest

截至2026年9月2日，@nestjs/core 的 npm latest 版本已是 12.0.1。NestJS 12.0.0 作为 v12 这条大版本线的首个正式版本正式发布。这意味着从现在开始，所有使用 npm install @nestjs/core 的开发者默认会拉取 12.x 版本。

这个时间节点标志着 NestJS 团队对 v12 的稳定性有了足够信心。过去几个月里，社区围绕 12.0.0-rc 版本进行了大量测试和反馈，最终在 2026 年 9 月初完成了正式版的推送。npm 状态的切换也直接影响了新项目的初始化体验，create-nestjs-app 等脚手架工具会自动采用最新稳定版。

对于关注 NestJS 版本演进的开发者来说，这次发布不是小修小补，而是包含了构建工具和模块系统的双重重大调整。12.0.1 的快速跟进也表明团队在正式版推出后立即修复了少量边缘问题，确保 latest 版本可用性。当前 npm 页面显示的 latest 标签清晰指向 12.0.1，这为后续的生态工具适配提供了明确基准。

版本发布时间的确定性也让企业用户能够规划升级路线。许多团队习惯等待首个正式版后再大规模采用，现在可以放心地将 NestJS 12 纳入技术栈评估范围。npm 状态的变化同时意味着文档、示例代码和第三方包的兼容性声明都需要快速更新到 v12 标准。

这一变化的直接结果是，新建项目的默认配置已经完全不同。开发者不再需要手动指定版本或构建工具，脚手架会直接给出基于 Rspack 和 ESM 的项目模板。这为后续章节讨论的具体技术切换奠定了基础。

新项目默认构建工具切换为 Rspack

NestJS 12 将新项目的默认构建工具从 Webpack 切换至 Rspack。这一决定直接影响了项目启动速度和开发体验。Rspack 作为 Rust 实现的 bundler，在冷启动和增量编译上比 Webpack 有显著优势，尤其在大型 NestJS 单体应用中体现明显。

性能优势主要体现在两个方面。首先是构建速度，Rspack 利用 Rust 的高性能多线程能力，在典型 NestJS 项目上能将冷启动时间缩短 50% 以上。其次是内存占用更低，避免了 Webpack 在处理大量 TypeScript 文件时容易出现的 OOM 问题。这些优势让 Rspack 成为新项目默认选项，因为新项目没有历史包袱，可以直接享受现代构建工具带来的红利。

为什么选择 Rspack 而不是继续优化 Webpack？核心原因是生态定位。Rspack 兼容 Webpack 的绝大部分配置，同时提供了更快的编译管道。NestJS 团队在 v12 中将默认的 webpack.config.js 替换为 rspack.config.js，并内置了针对 NestJS 控制器、服务和模块的优化规则。新项目运行 npm run build 时，后台实际调用的是 Rspack，这一点在生成的 package.json scripts 中可以清晰看到。

对新项目而言，这一切换几乎是无感知的。开发者仍然使用熟悉的 nest build 命令，但底层执行效率更高。在 CI/CD 流水线中，构建时间缩短也意味着更快的部署节奏。对于追求开发体验的团队来说，默认采用 Rspack 降低了入门门槛，特别是对新接触 NestJS 的前端转后端开发者。

Rspack 的插件生态虽然仍在发展，但核心的 TypeScript 支持、装饰器处理和静态资源打包已经足够成熟。NestJS 12 的官方模板中已经包含了必要的 rspack 插件配置，确保装饰器元数据和模块解析行为与之前保持一致。这为全面转向 ESM 打下了技术基础。

全面转向 ESM 模块规范的兼容性变化

NestJS 12 全面转向 ESM 模块系统，这意味着项目默认使用 import/export 而非 require/module.exports。这一变化直接影响模块加载方式和项目结构。

在模块加载方面，NestJS 现在强制使用 ES 模块的静态分析能力。以前 CommonJS 下的动态 require 现在必须改写为 import，这让模块解析更可预测，也为 tree-shaking 提供了更好条件。项目结构上，package.json 需要明确设置 “type”: “module”，或者将文件后缀改为 .mjs。NestJS 官方模板已经完成了这一配置，但存量代码迁移时需要逐一检查。

兼容性变化最明显的地方在于第三方包。如果某个依赖仍然只提供 CommonJS 输出，NestJS 12 会通过 Node.js 的 ESM 兼容层进行加载，但这可能带来额外的启动开销。装饰器和元数据反射机制在 ESM 下仍然正常工作，因为 NestJS 内部已经调整了 reflector 的实现方式。

项目结构调整还包括 tsconfig.json 的 module 设置需要改为 ESNext 或 NodeNext。这会影响路径别名和 barrel 文件的解析方式。以前常见的 index.ts 导出多个模块的写法在 ESM 下需要更明确的 export * from 语法，否则可能出现循环依赖问题。

转向 ESM 也带来了更好的异步加载支持。NestJS 的动态模块现在可以更自然地使用 top-level await，这在配置数据库连接或加载远程配置时特别有用。整体来看，这一变化让 NestJS 的模块系统更接近现代 JavaScript 标准，但也要求开发者重新审视现有代码中所有 require 语句。

这些兼容性调整不是孤立的，而是与 Rspack 的构建流程紧密结合。Rspack 对 ESM 的原生支持比 Webpack 更彻底，这也是两者共同升级的重要原因。

存量项目升级 v12 的迁移路径与风险

存量项目升级到 NestJS 12 需要谨慎规划。核心迁移路径分为三步：首先更新 package.json 中的版本，其次调整构建配置，最后处理 ESM 相关 breaking changes。

升级命令很简单，执行 npm install @nestjs/core@12 @nestjs/common@12 即可。但随后必须将 webpack 相关配置迁移到 Rspack，并添加 “type”: “module”。这一步最容易出现问题的是 babel 或 ts-node 的配置，因为 ESM 下它们的加载方式完全不同。

可能遇到的 breaking changes 主要集中在模块解析和测试环境。Jest 测试框架需要额外配置才能支持 ESM，常见的 jest.config.js 要改为 jest.config.mjs，否则会出现 SyntaxError。部分社区包如果没有及时发布 ESM 版本，也会导致运行时错误。

实际影响取决于项目规模。小型项目可能一天内完成迁移，而包含数十个模块和复杂依赖的企业应用则需要几周时间进行回归测试。最大的风险在于隐式的 CommonJS 依赖被 ESM 严格模式暴露出来，导致启动失败或循环依赖错误。

迁移路径的推荐做法是先创建一个新项目模板，对比新旧项目的差异，然后逐步应用到存量代码。NestJS 团队提供了迁移指南，但目前仍处于早期阶段，部分边缘场景的处理方案还不完善。建议在非生产分支进行升级，并准备好回滚方案。

尽管存在风险，但升级带来的性能收益是实实在在的。完成迁移的项目在开发模式下的热更新速度明显加快，这对日常开发效率提升显著。

Rspack 与 ESM 结合对 NestJS 生态的定位

NestJS 12 将 Rspack 与 ESM 结合，标志着这个流行 Node.js 框架向现代 JavaScript 工具链进一步靠拢。这一变化在行业中的位置是追赶前沿而非引领潮流，但对中文开发者社区具有长期意义。

当前主流后端框架中，Fastify 和 tRPC 早已拥抱 ESM，NestJS 的这次转向让它不再落后于潮流。Rspack 作为国人主导的高性能 bundler，其被 NestJS 官方采用，也体现了中文技术社区在底层工具上的影响力正在扩大。

对生态的定位而言，这一组合强化了 NestJS 在大型企业应用中的优势。ESM 带来的更好静态分析能力有助于代码分割和懒加载，而 Rspack 的速度则降低了构建成本。这对微服务架构下的 NestJS 项目特别友好，因为每个服务都可以快速独立构建。

中文开发者社区将从中学到更多 Rust 和 ESM 的实战经验。过去 Webpack 配置问题常常成为新手障碍，现在 Rspack 的简洁配置降低了这一门槛。长期来看，这有助于更多中文团队将 NestJS 用于生产环境，而不是仅仅停留在学习阶段。

这一变化也为后续的 NestJS 功能演进铺路。未来版本很可能进一步利用 ESM 的原生特性开发新的模块加载机制，或集成更多 Rust 编写的性能关键组件。在全球 Node.js 生态中，NestJS 12 的定位从「可靠的企业框架」进一步升级为「跟上现代构建工具的可靠企业框架」。

开发者在新旧项目中的实际选择建议

对新项目，建议直接使用 NestJS 12 的官方脚手架。它已经内置 Rspack 和 ESM 配置，开发者可以专注于业务逻辑而非构建工具调优。选择 TypeScript 的项目需要确保 tsconfig.json 的 target 和 module 设置与 ESM 兼容。

对于存量项目，如果项目规模较小且依赖较新，建议尽快规划升级；如果项目庞大且已稳定运行，建议继续使用 v11，直到团队有足够时间完成全面迁移。目前还不清楚 NestJS 团队会将 v11 维护多长时间，但可以预期安全更新仍会持续一段时间。

中文读者在实际操作中应特别注意中文文档的更新滞后问题。英文官方文档通常先更新，社区中文教程可能需要几周时间跟进。建议优先参考 NestJS 官方 GitHub 的 migration guide，并加入相关技术交流群获取最新实践。

尚未完全确定的部分包括 Rspack 在 Windows 环境下的长期稳定性，以及部分企业内部包对 ESM 的支持程度。这些问题需要在实际项目中逐步验证。总体建议是，新项目大胆采用，新技术红利明显；老项目稳妥评估，优先保证业务连续性。

开发者还应开始熟悉 ESM 的 import 语法和 top-level await，这些能力在 NestJS 12 中会越来越常用。结合 Rspack 的性能优势，这一版本为 NestJS 在下一阶段的竞争中提供了坚实基础。

参考来源