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

4. Website redesign

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

5. Minor breaking changes

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

6. 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

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

[kamilmysliwiec]

@angelhodar yeah we will just use vitest with oxc instead of vitest + swc. For bundling (monorepos) you could use rspack. For regular apps tsc/swc depending on what you prefer

[vaskouk]

Hey! In v12 how decorators like @Body will validate such?

@Body() payload: CreateCustomBrandPayloadDto

[kamilmysliwiec]

Nothing changes here @vaskouk, you can still use ValidationPipe with class-validator.

[vaskouk]

Nothing changes here @vaskouk, you can still use ValidationPipe with class-validator.

Sorry i didn't phrase it correctly, with class-validator yes, but what if someone wants to switch to zod schema validation. ValidationPipe will still do the work?

[kamilmysliwiec]

If you want to use zod, you need to use zod schemas, not classes with annotations.

[vaskouk]

If you want to use zod, you need to use zod schemas, not classes with annotations.

Yes got it, so the same like @Body() payload: CreateCustomBrandPayloadSchema ? which will be the zod schema

[kamilmysliwiec]

See 35-zod-validation sample in this PR

[angelhodar]

@angelhodar yeah we will just use vitest with oxc instead of vitest + swc. For bundling (monorepos) you could use rspack. For regular apps tsc/swc depending on what you prefer

Great! So for bundling its not possible to use Vite too? I was thinking if Vite could be the underlying tool for everything in nest (dev server + bundling + vitest), but as far as I understand from your answer its not possible right now with vite 8?

[wonderbeel]

@angelhodar yeah we will just use vitest with oxc instead of vitest + swc. For bundling (monorepos) you could use rspack. For regular apps tsc/swc depending on what you prefer

Great! So for bundling its not possible to use Vite too? I was thinking if Vite could be the underlying tool for everything in nest (dev server + bundling + vitest), but as far as I understand from your answer its not possible right now with vite 8?

In theory yes it is possible (I tried it a couple of months ago and for an hello world app it worked) using the environment API at least for production bundling, the big problem is the dev server because it is tailor made for the browser and always expect to inject into an html page, you can probably do something with a script that runs build in watch mode + nodemon or something similar to restart the server every time but it sounds hackish to me.

It would be great to have a consistent environment for everything indeed (another nice thing would be to be able to create a single executable for distroless containers) but probably it is up to Kamil if he wants to try to reach to voidzero and figure out if it would indeed be possible to use Vite for everything in the nest cli.

[kamilmysliwiec]

Vite is great but i dont think it's really necessary for a Nest app.

• vitest - sure it makes perfect sense (that's why we migrated)
• oxc - can be integrated with the Nest CLI but i dont see much benefit given that we already have swc builder available
• bundling - you don't really need it for a Node app. Might be useful in a monorepo (to have a "single deployable artifact" and to bundle local libs), but that's why we have Rspack integrated (in v12, originally Webpack).

[anotheri]

@kamilmysliwiec it's definitely not necessary and both swc and rspack are amazing tools! But it'd be great addition to have a chose between swc and oxc for @nestjs/cli, as well as vite or rspack for bundling a monorepo, not necessary for v12.0 but maybe worth to consider it later.

Nevertheless i'm quite excited about v12 and looking forward to try it, thanks a lot for your effort improving Nestjs!

[vaskouk]

Vite is great but i dont think it's really necessary for a Nest app.

• vitest - sure it makes perfect sense (that's why we migrated)
• oxc - can be integrated with the Nest CLI but i dont see much benefit given that we already have swc builder available
• bundling - you don't really need it for a Node app. Might be useful in a monorepo (to have a "single deployable artifact" and to bundle local libs), but that's why we have Rspack integrated (in v12, originally Webpack).

So rspack will be come integated in v12? For example i am using rspack with my own config in v11, this will become obsolete or i missunderstood?

[kamilmysliwiec]

@vaskouk

[pasha-vuiko]

As I see you NestJS is going to use Vite and Oxc stuff by default for ESM, wasn't you thinking about integration with Vite+ somehow?

[kamilmysliwiec]

@pasha-vuiko

[kraikov]

Amazing. What would be the best way to migrate a large codebase to v12?
Are we getting a migration guide?

[13RTK]

Amazing. What would be the best way to migrate a large codebase to v12? Are we getting a migration guide?

You should find solutions in the ORM's official docs that depend on the ORM you are using

[vaskouk]

Hey! When can we have alpha version for all packages (specially swagger etc) to test the new versions?

[AndrewBoklashko]

Hi there

Excited to see lots of great things coming in NestJS v12 🚀

For bundling (monorepos) you could use rspack.

Wanted to share use case of our monorepo and NestJS-related issue with it. In a hope that things become smoother in v12 or future releases.

Our monorepo uses pnpm workspaces + Turborepo(NestJS monorepo library mode is not used). We have a couple of internal packages referenced by NextJS frontend and NestJS backend apps. A difficulty is that while NextJS supports direct transpilation using transpilePackages config, NestJS does not have anything like that so we cannot use Turborepo Just-In-Time packages and have to fallback to Compiled Packages.

Not a blocker as Compiled Packages serve good enough but still our monorepo setup would be even simpler if NestJS supported some equivalent to NextJS transpilePackages.

P.S. I'm not very familiar with rspack, could be that it supports such configuration

Apologize upfront if this is a wrong place to post my feedback.