release: v12.0.0 major release (approx. Q3 2026)

[kamilmysliwiec]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe: v12.0.0 release

Description

Approximate release window: early Q3 2026

Overview

1. ESM migration

   • All NestJS packages will transition from CommonJS (CJS) to ESM. The packages in this repository (core, common, etc.) have already been migrated. (build: migrate from cjs to esm #16369)
   • This should not introduce major breaking changes for existing projects thanks to Node.js require(esm) support.
   • The availability of require(esm) was the missing piece that made the move to ESM practical - without it, the migration wouldn't have made much sense. https://joyeecheung.github.io/blog/2024/03/18/require-esm-in-node-js/ https://nodejs.org/api/esm.html#require

2. CLI (ESM/CJS)

   • The NestJS CLI will prompt users to choose whether to generate a CJS or ESM project (ESM projects will use vitest + oxlint by default)
   • Webpack -> Rspack ✅ (webpack is now deprecated)

3. Testing stack changes

   • All repositories and sample projects will move from Jest to Vitest (with OXC for TypeScript decorator support). refactor: migrate from mocha, chai, sinon to vitest #16370 sample: migrate all samples to esm and vitest #16371 chore: upgrade to vitest 4 with oxc #16672
   • New ESM projects will use Vitest by default.
   • The CJS schematic will continue to use Jest.

4. Linter

   • All projects will now use oxlint instead of eslint by default chore: migrate to oxlint from eslint #16674

5. Website redesign

   • A complete redesign of the NestJS websites is coming soon - we're taking them to the next level.

6. Minor breaking changes

   • There will be a few minor breaking changes across other NestJS packages, but nothing significant.

7. Schema support in route decorators

   • All route decorators (e.g., @Body, @Query, etc.) will support a new schema option that accepts a Standard Schema–compatible object. https://standardschema.dev/)
   • This enables the use of modern validation libraries such as Zod, Valibot, ArkType, and others, as an alternative to class-validator.
   • The same capability will also be available in the serializer interceptor.

PRs:

• build: migrate from cjs to esm #16369
• refactor: migrate from mocha, chai, sinon to vitest #16370
• sample: migrate all samples to esm and vitest #16371
• refactor: minor codebase tweaks #16372
• feat: standard schema validation pipe, and standard serializer, introduce internal export subpath #16373
• feat(websockets): add disconnect reason parameter #16374
• feat(common): add error format option to validation pipe #16329
• Feat/express graceful shutdown #16156
• refactor: update pipe transform signatures for improved type safety #16147
• feat(common): allow passing errorCode in HttpExceptionOptions #15525
• feat(common): add generic for argument metadata #15413
• feat(microservices): nats v3 upgrade #15190
• refactor(core,express,fastify): HTTP adapter error mapping #15075
• feat(core): call hooks by components hierarchy level (order) #14900
• test(common): improve test coverage for shared utils #14832
• fix(core): make isHttpError check stricter #14753
• feat(common): add structured logging params support #16464
• Feat/microservices pre request hook v12 #16429
• chore: upgrade to vitest 4 with oxc #16672
• chore: migrate to oxlint from eslint #16674
• feat(microservices): add grpc exception filter #16945
• fix(microservices): support regex Kafka patterns #16943
• feat(websockets): request-scoped gateways #16949

Packages will soon (possibly in Q2) be released under the next tag to let everyone play with them before they make it to the official latest tag.

Does this PR introduce a breaking change?

• Yes
• No

Other information

[pasha-vuiko]

what minimal Node.js version is planned to be supported in NestJS v12?

[emran-niftyitsolution]

need bun and biome selection option from cli when creating new nestjs project.

[pradelgorithm]

What would be the support for TS 6+7 given the release?

https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-beta/

[kamilmysliwiec]

@pradelgorithm AFAIK both v6 and v7 already work with the current version of Nest

[SchroederSteffen]

AFAIK both v6 and v7 already work with the current version of Nest

Maybe, but @nestjs/cli defines a hard dependency to 5.9.3: https://github.com/nestjs/nest-cli/blob/cabbe0b0caa652b04bc172c26a31a3c40d6b1bd3/package.json#L56

It would be great if this could be widened in v11.
v12 in Q3 is still months away.

[kamilmysliwiec]

@SchroederSteffen @nestjs/cli always loads the local typescript package (for building), if exists. Just install v6 in your project and the CLI should pick it up automatically

[SchroederSteffen]

@nestjs/cli always loads the local typescript package (for building), if exists. Just install v6 in your project and the CLI should pick it up automatically

Correct, but then we end up with two typescript installations which we would like to avoid.
It also means that we're technically violating the version requirements as stated by NestJS.

[kamilmysliwiec]

Correct, but then we end up with two typescript installations which we would like to avoid.

1. No need for ts in prod with Docker multi-stage builds
2. Can always use "overrides" to override CLI's version if 2 installations worry you

It also means that we're technically violating the version requirements as stated by NestJS.

No version requirement violations, it's just a local ts copy in case someone doesn't install one in their projects. The core package (and others) doesn't really list TS as a requirement, nor specify any version that should be used.

[imorius]

I think we should support other build tools besides SWC, such as Bun's built-in build or tsdown (based on Rolldown), for compatibility with Bun.

[gperdomor]

Any plans for new alphas? The current ones create a project with v11

[kamilmysliwiec]

@imorius AFAIK bun is already supported. you can also use OXC compiler (from vite) with no issues

[kamilmysliwiec]

For those who want to give v12 a shot, all packages have just been released under the next tag on NPM:

• @nestjs/common: 12.0.0-alpha.4
• @nestjs/core: 12.0.0-alpha.4
• @nestjs/microservices: 12.0.0-alpha.4
• @nestjs/platform-express: 12.0.0-alpha.4
• @nestjs/platform-fastify: 12.0.0-alpha.4
• @nestjs/platform-socket.io: 12.0.0-alpha.4
• @nestjs/platform-ws: 12.0.0-alpha.4
• @nestjs/testing: 12.0.0-alpha.4
• @nestjs/websockets: 12.0.0-alpha.4

$ npm i {package_name}@next

if you want to start from scratch, you can also just use npx @nestjs/cli@next new (might need a local @nestjs/schematics@next version installed if you already have a globally installed binary - otherwise it may pick up the old version)

[gabroberge]

First of all, thanks for the changes introduced in the upcoming NestJS 12 release. I’ve been testing the new standard schema validation setup and overall the direction looks really promising.

While testing with ArkType in the default setup, I noticed what seems to be a serialization issue when validation fails. The validation itself works correctly, but invalid payloads end up throwing a 500 instead of returning a proper 400 response.

It looks like the ArkType validation error object is propagated directly to the HTTP response layer, where JSON serialization fails (TypeError: e.toJSON is not a function).

I haven’t added any custom ArkType integration code on my side, this happens with the default setup.

Not sure if this is already known given the pre-release state, but I figured it was worth reporting.