NestJS 12 moves to ESM packages, adds Standard Schema validation and observability SDK

Major update modernises tooling and validation while keeping CommonJS projects working

By LineZotpaper

Published19 October 2026

Read Time3 min

NestJS, the TypeScript framework for building server-side Node.js applications, has released version 12, a major update that moves its core packages to ESM, adds first-class Standard Schema validation, rebuilds the CLI and introduces an official observability SDK.

The ESM change headlines the release, largely because it asks so little of existing teams. Core packages now ship as ESM, but CommonJS applications keep working through Node.js's require(esm) support, which is why v12 requires Node.js 20.19+ or 22.12+. The nest new command now asks whether to generate a CommonJS or ESM project, with ESM projects defaulting to Vitest and oxlint, while Rspack replaces webpack as the monorepo bundler.

Developer Anton Chapala's preview benchmarks found no meaningful startup or memory gains from ESM, concluding it "is a massive cleanup of tooling and configuration debt" rather than a performance upgrade.

Day-to-day ergonomics change most around validation. Route decorators such as @Body(), @Query() and @Param() accept a schema option taking any Standard Schema compatible object, so Zod, Valibot and ArkType work without third-party wrappers once the new pipe is registered. class-validator remains the documented default. Blogger iiaku argued that building on a spec rather than on Zod directly "keeps the choice in my hands while removing the boilerplate", though a commenter on ByteIota's preview coverage noted that types must still be annotated by hand because Nest continues to rely on legacy TypeScript decorators.

The most debated addition is @nestjs/observe, which hooks into 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 acknowledged the richer context but warned the SDK is "NestJS-only", lacks cross-stack correlation out of the box and risks "vendor lock-in at the framework level". A new nest deploy command, forwarding to the Mau platform, points the same way towards first-party services.

Upgrading from v11 means installing the latest CLI with npm i -g @nestjs/cli@latest and running nest upgrade, which moves every @nestjs/* package to v12, bumps TypeScript to v6 and applies mechanical changes such as the GraphQL Playground to GraphiQL switch and the NATS v3 client swap. It deliberately does not convert projects to ESM, Vitest or oxlint. The migration guide covers the rest, including lifecycle hook ordering and Joi v18. One GitHub issue prompted docs noting AWS Lambda runtimes need --experimental-require-module, while others report path aliases breaking under ESM and Fastify middleware exceptions hanging.

The follow-up v12.1 has since added built-in cookies, CSRF protection and security headers. NestJS is an open-source, MIT-licensed framework for building scalable server-side applications with TypeScript. It combines an Angular-inspired module and dependency injection architecture with Express and Fastify support, and has more than 76,000 stars on GitHub.

Analysis

Why This Matters

The ESM move aligns NestJS with Node.js's modern module system without forcing current CommonJS projects to convert, a significant decision for one of the most widely used TypeScript server frameworks.
Standard Schema support changes how validation is approached across the Nest ecosystem, letting developers pick Zod, Valibot or ArkType without wrappers.
First-party observability and deploy tooling signal NestJS expanding from a framework into a fuller platform, with commercial implications for the project's long-term direction.

Background

NestJS has established itself as one of the leading frameworks for structured, enterprise-style Node.js applications, drawing its module system and dependency injection design from Angular while running on Express or Fastify underneath. The project is open source under an MIT licence and has built a large community over successive major releases. Version 12 follows the roadmap the maintainers set out in April and lands amid a broader Node.js ecosystem shift towards ESM.

Key Perspectives

Framework users: Get a cleaner toolchain and more choice in validation, with the upgrade path deliberately not forcing ESM, Vitest or oxlint onto existing projects.

APM vendors and observability providers: Scout Monitoring's caution highlights the trade-off: richer Nest-aware context but a NestJS-only view that lacks cross-stack correlation and risks framework-level lock-in.

Skeptics: Preview benchmarks found no performance benefit from ESM, and the continued reliance on legacy TypeScript decorators means validation schema types must still be annotated by hand.

What to Watch

Whether an ESM-first NestJS pushes other Node.js frameworks and libraries to accelerate their own ESM migrations.
How quickly the community adopts Standard Schema validation, and whether it becomes the recommended path over class-validator.
The growth of first-party services: the Observe SDK and the Mau deploy platform expand NestJS's commercial surface and will shape how the project is funded and maintained.

Sources

NestJS 12: ESM Packages, Standard Schema Validation and Native Observability · InfoQ

Checked

12 claims in this story checked against 1 source: 12 supported.

Show each claim

SupportedNestJS 12 moves to ESM packages, adds Standard Schema validation and observability SDK.InfoQ: “has released version 12 , a major release that moves its core packages to ESM, adds first-class Standard Schema validation, rebuilds the CLI and introduces an official observability SDK.”
SupportedNestJS 12 is a major update that modernises tooling and validation while keeping CommonJS projects working.InfoQ: “a major release that moves its core packages to ESM, adds first-class Standard Schema validation ... CommonJS applications keep working through Node.js require(esm) support”
SupportedCore packages now ship as ESM, but CommonJS applications keep working through Node.js require(esm) support; v12 requires Node.js 20.19+ or 22.12+.InfoQ: “Core packages now ship as ESM, but CommonJS applications keep working through Node.js require(esm) support, which is why v12 requires Node.js 20.19+ or 22.12+.”
Supportednest new asks whether to generate a CommonJS or ESM project; ESM projects default to Vitest and oxlint; Rspack replaces webpack as the monorepo bundler.InfoQ: “nest new now asks whether to generate a CJS or ESM project, with ESM projects defaulting to Vitest and oxlint, while Rspack replaces webpack as the monorepo bundler.”
SupportedAnton Chapala's preview benchmarks found no meaningful startup or memory gains from ESM, concluding it "is a massive cleanup of tooling and configuration debt" rather than a performance upgrade.InfoQ: “Developer Anton Chapala's preview benchmarks found no meaningful startup or memory gains from ESM, concluding it "is a massive cleanup of tooling and configuration debt" rather than a performance upgrade.”
SupportedRoute decorators @Body(), @Query() and @Param() accept a schema option taking any Standard Schema compatible object; Zod, Valibot and ArkType work without third-party wrappers; class-validator remains the documented default.InfoQ: “Route decorators such as @Body() , @Query() and @Param() accept a schema option taking any Standard Schema compatible object, so Zod , Valibot and ArkType work without third-party wrappers once the new pipe is registered. class-validator remains the documented default.”
SupportedBlogger iiaku said building on a spec rather than Zod directly "keeps the choice in my hands while removing the boilerplate".InfoQ: “Blogger iiaku argued that building on a spec rather than on Zod directly "keeps the choice in my hands while removing the boilerplate"”
SupportedA commenter on ByteIota's preview coverage noted that types must still be annotated by hand because Nest relies on legacy TypeScript decorators.InfoQ: “a commenter on ByteIota's preview coverage noted that types must still be annotated by hand because Nest continues to rely on legacy TypeScript decorators”
Supported@nestjs/observe hooks into Nest's own lifecycle through an instrument option instead of patching the HTTP server, reporting traces in terms of controllers and providers.InfoQ: “The most debated addition is @nestjs/observe , which hooks into Nest's own lifecycle through a new instrument option instead of patching the HTTP server, reporting traces in terms of controllers and providers.”
SupportedScout Monitoring said the SDK is "NestJS-only", lacks cross-stack correlation out of the box, and risks "vendor lock-in at the framework level".InfoQ: “APM vendor Scout Monitoring acknowledged the richer context but warned the SDK is "NestJS-only", lacks cross-stack correlation out of the box and risks "vendor lock-in at the framework level".”
SupportedUpgrading from v11 means installing the latest CLI, running nest upgrade, which moves every @nestjs/* package to v12, bumps TypeScript to v6, applies the GraphQL Playground to GraphiQL switch and NATS v3 swap; it does not convert projects to ESM, Vitest or oxlint.InfoQ: “installing the latest CLI with npm i -g @nestjs/cli@latest and running nest upgrade , which moves every @nestjs/* package to v12, bumps TypeScript to v6 and applies mechanical changes such as the GraphQL Playground to GraphiQL switch and the NATS v3 client swap. It deliberately does not convert projects to ESM, Vitest or oxlint.”
SupportedNestJS has more than 76,000 stars on GitHub.InfoQ: “has more than 76,000 stars on GitHub.”