NestJS, the TypeScript framework for building server-side Node.js applications, has released version 12, a major update that shifts its core packages to ECMAScript Modules while keeping CommonJS applications functional through Node.js compatibility features. The release, announced by creator Kamil Myśliwiec in a post that drew more than 1,100 likes and 66,000 views, follows the roadmap published in April and introduces first-class Standard Schema validation, a rebuilt command-line interface, and an official observability SDK. The ESM transition stands as the headline change, largely because existing teams can adopt it with minimal disruption.
Core packages now ship as ESM, but CommonJS projects continue to work thanks to Node.js require(esm) support, which explains why version 12 requires Node.js 20.19 or later, or 22.12 and above. The nest new command now prompts developers to choose between generating a CommonJS or ESM project, with ESM builds defaulting to Vitest and oxlint as their testing and linting tools, while Rspack takes over from webpack as the monorepo bundler. Developer Anton Chapala ran preview benchmarks and found no significant startup or memory improvements from the ESM shift, calling it "a massive cleanup of tooling and configuration debt" rather than a performance boost. Validation workflows see the most practical change: route decorators like @Body(), @Query(), and @Param() now accept a schema option that takes any Standard Schema compatible object, meaning Zod, Valibot, and ArkType function without third-party adapters once the new pipe is registered, though class-validator remains the documented default.
Blogger iiaku argued that anchoring the feature to a specification instead of directly to Zod "keeps the choice in my hands while removing the boilerplate", though a commenter on ByteIota's preview coverage pointed out that types still require manual annotation because Nest relies on legacy TypeScript decorators. The most controversial addition is @nestjs/observe, which connects to Nest's own lifecycle through a new instrument option instead of patching the HTTP server, reporting traces in terms of controllers and providers. APM vendor Scout Monitoring recognized the richer context but cautioned the SDK is "NestJS-only", lacks cross-stack correlation out of the box, and creates potential vendor lock-in at the framework level, while a new nest deploy command that forwards to the Mau platform signals a similar move toward first-party services.
Moving from version 11 to 12 involves installing the latest CLI with npm i -g @nestjs/cli@latest and running nest upgrade, which updates every @nestjs/* package to version 12, raises TypeScript to version 6, and applies mechanical changes such as swapping GraphQL Playground for GraphiQL and adopting the NATS v3 client. The command deliberately avoids converting projects to ESM, Vitest, or oxlint, leaving those decisions to developers, while the migration guide covers the rest, including lifecycle hook ordering and Joi v18. One GitHub issue triggered documentation noting that AWS Lambda runtimes need the --experimental-require-module flag, while other users reported path aliases breaking under ESM and Fastify middleware exceptions hanging, though the follow-up release version 12.1 has since added built-in cookies, CSRF protection, and security headers. NestJS is an open-source, MIT-licensed framework for building efficient and scalable server-side applications with TypeScript, combining an Angular-inspired module and dependency injection architecture with Express and Fastify support, and has more than 76,000 stars on GitHub. The shift to ESM and Standard Schema reflects the framework's bet that long-term maintainability and ecosystem flexibility matter more than immediate performance gains, a choice that may appeal to teams prioritizing technical debt reduction over speed optimization. Organizations weighing the upgrade will need to consider whether framework-level observability tooling offers enough operational visibility to justify potential migration complexity, especially if their monitoring infrastructure spans multiple languages or runtimes.