NestJS 12 goes ESM-first and opens validation to Zod, loosening two of its longest-standing constraints
NestJS 12 ships every official package as ESM and adds Standard Schema support, so route decorators accept Zod, Valibot, or ArkType alongside class-validator. CommonJS apps keep working, making this real modernization without a forced rewrite.
NestJS 12 is the framework’s most consequential release in years, and it spends its major version number loosening two constraints that have shaped how teams use it. Every official package now ships as ESM, and route decorators can validate against the Standard Schema spec, which means Zod, Valibot, and ArkType become first-class options next to the class-validator approach NestJS has leaned on since its early days. A rebuilt CLI and a native observability SDK round out a release that reads less like new surface area and more like NestJS catching up to where the rest of the Node ecosystem already moved.
ESM without the forced rewrite
The headline change is that all of NestJS’s own packages are now published as ECMAScript modules. That matters because NestJS has long been one of the larger reasons teams stayed on CommonJS: its decorator-heavy, TypeScript-first design was wired to the CJS toolchain, and that made it awkward to sit alongside the growing set of ESM-only libraries in the npm ecosystem. Version 12 flips that default.
The important qualifier is that existing CommonJS applications keep working. NestJS leans
on Node.js’s ability to require an ESM module, so migrating your own code to ESM is
optional rather than a precondition for upgrading. For a working team, that is the
difference between a version bump you can schedule and a rewrite you have to budget: you
collect the compatibility win now and move your own modules when it suits you.
Standard Schema is the quietly bigger shift
The change with the longest tail may be Standard Schema support. Route decorators such as
@Body(), @Query(), and @Param() now accept a schema option compatible with the
Standard Schema specification, so a Zod, Valibot, or ArkType schema can drive validation
and typing directly. class-validator and its decorator classes still work and are not
going away, but they are no longer the only sanctioned path.
For developers, this closes a friction point that pushed some teams toward lighter frameworks. Zod has become the default validation layer for much of the TypeScript world, and wiring it into NestJS previously meant custom pipes and a certain amount of fighting the framework’s conventions. Making a single schema the source of truth for both runtime validation and static types, inside the decorator API rather than bolted onto it, is NestJS meeting its users where they already are rather than asking them to adopt a second validation vocabulary.
A rebuilt CLI and observability that hooks the framework, not the process
The tooling gets the same modernization. The CLI was rebuilt in ESM and adds commands
including nest upgrade, which automates much of the mechanical migration to v12, and a
nest deploy command. Alongside the release, the new @nestjs/observe SDK provides
built-in instrumentation that hooks into Nest’s own request lifecycle, controllers,
interceptors, resolvers, and queue consumers, rather than wrapping the process in a
generic Node.js agent. Auto-instrumentation spans HTTP, GraphQL, gRPC, and microservice
transports.
The distinction is worth drawing out for anyone who has instrumented a Node service: a generic APM agent sees spans and timings but not the framework’s structure, while an SDK that understands controllers and interceptors can attribute latency to the layer that caused it. That is observability designed for how NestJS apps are actually shaped.
Where the upgrade cost lands
The breaking changes are the expected consequence of an ESM-first release. NestJS 12
requires Node.js v20.19+ or v22.12+ and drops support for the 21.x line, the NATS
transport moves to a new package, and GraphQL subscriptions over the retired
subscriptions-transport-ws need to migrate to graphql-ws. Config validation shifts
from a Joi-specific option to the Standard Schema approach. The nest upgrade command
handles most of the mechanical work, but the Node version floor and the transport changes
are the items to check before scheduling the move.
What it means
NestJS 12 is a maturity release, not a reinvention: it takes two long-standing frictions,
CommonJS lock-in and a single blessed validation library, and turns both into choices.
The ESM default keeps NestJS compatible with an ecosystem that moved on, Standard Schema
support meets the Zod-shaped reality of TypeScript development, and the observability SDK
signals that NestJS wants to own more of the production story, not just the request
handler. For teams already on Nest, the path is straightforward: confirm the Node floor,
run nest upgrade, and treat ESM and Zod-based validation as incremental adoptions rather
than a same-day rewrite.