NestJS 12 is on the horizon. The work toward the next major release is already underway in the main framework repository, and the high-level plan is now public in this release PR.

The current target is early Q3 2026, and while the release is still in progress, the direction is already clear: NestJS 12 will modernize the platform around ESM, refresh the default tooling, and introduce a few new framework capabilities that many people have been waiting for.

In case you're not familiar with NestJS, it is a TypeScript Node.js framework that helps you build enterprise-grade efficient and scalable Node.js applications.

Let's take a look at what's changing.

What's coming in NestJS 12?

This release is not about one isolated feature. It is a broader platform update that touches package format, CLI defaults, testing, linting, and a few framework internals.

Here are the most important themes.

NestJS is moving to ESM

The biggest architectural change in v12 is the move from CommonJS to ESM across the NestJS core packages.

‼️ The important nuance is that this is expected to be much less disruptive than an ESM migration would have been a few years ago. Modern Node.js now supports require(esm), which means many existing projects should be able to adopt the new packages without a dramatic rewrite. ‼️

That said, this is still a major shift and you should expect to review:

• custom build scripts
• custom CLIs and code generation tools
• deep imports into Nest internals
• module resolution assumptions in tsconfig.json
• import path conventions in projects that decide to go all-in on ESM

If you have been waiting for Nest to fully embrace the modern Node.js module story, v12 is that release.

The CLI will support both CJS and ESM projects

NestJS is not forcing every project into one module format overnight.

The Nest CLI will prompt you to choose whether you want to generate a CommonJS or ESM project. That is an important detail because it makes the migration path much more practical for teams that want to move gradually.

The default tooling will differ depending on that choice:

• new ESM projects will use Vitest and oxlint by default
• the CJS schematic will continue to use Jest

This gives teams a way to experiment with the new stack without forcing a flag day across every existing codebase.

Webpack is being deprecated in favor of Rspack

Another notable tooling change is that Rspack is replacing webpack in the NestJS CLI story.

If your current setup depends on webpack-specific behavior, custom plugins, or CLI integrations, this is one of the areas you should evaluate early while trying the prerelease packages.

It is also worth calling out one point that came up in the release discussion: tsc remains the default compiler. The build pipeline is evolving, but the TypeScript compiler is not going away. We're going to support the upcoming TypeScript-Go version of the compiler as well in the future, but for now, tsc is still the default.

The default testing stack is changing

NestJS 12 continues the ecosystem shift toward Vitest.

Internally, the framework repositories and sample applications are moving from Jest, Mocha, Chai, and Sinon toward a Vitest-based setup. For developers starting new ESM projects, this means the out-of-the-box testing experience will feel much more aligned with the broader modern TypeScript ecosystem.

At the same time, CommonJS users are not being left behind. The CJS schematic will still generate Jest-based projects, which should make incremental adoption easier for existing teams. Also, existing Jest-based projects can continue to use Jest without any forced migration, so the change is mostly about new projects and the default experience!

oxlint becomes the default linter

NestJS 12 will use oxlint instead of eslint by default.

For new applications this mostly means faster setup and a more modern linting baseline. For existing projects, the practical implication is that you should treat v12 as a good opportunity to review custom lint rules, local eslint plugins, and repository conventions that may no longer fit the new defaults.

Again, this is not a forced migration. Teams can continue to use eslint if they prefer, but the default experience is moving toward oxlint!

Route decorators will support Standard Schema

One of the most interesting framework-level additions in v12 is new schema support in route decorators such as @Body(), @Query(), and similar parameter decorators.

The new option accepts a Standard Schema compatible object, which opens the door to validation flows built on libraries like:

• Zod
• Valibot
• ArkType

This is a meaningful change because it gives teams a first-class alternative to class-validator for request validation. The same idea is also planned for the serializer interceptor, which should make schema-driven request and response handling much more consistent.

@Post()
create(@Body({ schema: createCatSchema }) createCatDto: CreateCatDto) {
  return this.catsService.create(createCatDto);
}

Or with Zod directly in the decorator:

@Get(':id')
findOne(@Param('id', { schema: z.coerce.number().int().positive() }) id: number) {
  return this.catsService.findOne(id);
}

If you have been building Nest applications around schema-first validation already, v12 is shaping up to be a very important release.

Just to be clear, this is not a replacement for class-validator! It is an additional option that will allow teams to use a schema-first approach without having to rely on decorators or class-based validation. Our documentation will still suggest class-validator as the default for most use cases, but the new schema support is a welcome addition for teams that prefer a different approach.

A number of smaller framework improvements are landing too

The release PR also tracks a long list of incremental framework changes. Some of the more visible ones include:

• support for passing errorCode in HttpExceptionOptions
• improved type safety for pipe transform signatures
• structured logging parameter support
• better shutdown behavior when hooks reject
• NATS v3 support in microservices
• microservice pre-request hooks
• Kafka regexp patterns support
• gRPC exception filters
• GraphiQL is now the default playground for GraphQL
• request-scoped gateways for websockets
• route conflict diagnostics and specificity ordering in the core router

None of these changes alone defines the release, but together they make v12 feel like a substantial platform update rather than a packaging-only major.

What will likely change for existing projects?

The good news is that the release plan explicitly calls out only minor breaking changes outside of the broader ESM and tooling transition.

Still, you should expect NestJS 12 to affect projects in a few concrete ways:

• projects with custom tooling will need the most attention
• ESM adopters should verify import semantics and runtime assumptions carefully
• teams relying on webpack-specific behavior should test the new CLI flow early
• teams starting fresh on ESM should expect Vitest and oxlint instead of Jest and eslint
• libraries or applications that rely on private or deep imports should clean those up before upgrading

In other words, the biggest story in v12 is not one large runtime break. It is the modernization of the overall development experience.

How to try NestJS 12 today

Prerelease packages are being published under the next tag so the community can test the upcoming major before it reaches latest.

If you want to try the new release in an existing project, install the Nest packages you use from next:

npm i @nestjs/common@next @nestjs/core@next @nestjs/platform-express@next
### For other packages, just replace `{package_name}` with the package you want to install:
### npm i {package_name}@next

If you want to generate a new project using the upcoming CLI, use:

npx @nestjs/cli@next new

If you already have a globally installed Nest CLI binary, you may also want a matching local schematics package to avoid version mismatches while testing the new generators:

npm i -D @nestjs/schematics@next

This is especially relevant if the global binary picks up older defaults while your local workspace is meant to target the v12 prerelease flow.

NestJS websites are getting a long-awaited redesign

NestJS 12 is not only about changes inside the framework itself. The broader NestJS ecosystem is also getting a visual refresh, with a completely redesigned website that marks the first major redesign in roughly nine years.

The new website brings the project's online presence closer to the way modern developer platforms are expected to work today: cleaner, faster, more focused, and easier to navigate.

The redesign reflects how much the NestJS ecosystem has grown since the original website was launched. What started as a lightweight framework project has evolved into a widely adopted platform for building enterprise-grade Node.js applications, with a much larger community, documentation surface, and ecosystem of integrations.

While the website redesign is separate from the technical changes landing in NestJS 12, it represents the same broader direction: modernizing the project while keeping the core values that made NestJS popular — productivity, scalability, and a structured approach to building backend applications.

Final thoughts

NestJS 12 looks like a release with a clear long-term goal: modernize the framework without making the migration story unnecessarily painful.

The move to ESM, the new CLI split between CJS and ESM, Vitest for new ESM projects, oxlint by default, and Standard Schema support in route decorators all point in the same direction. Nest is aligning itself with the current Node.js and TypeScript ecosystem while still trying to preserve a practical path for existing teams.

If you maintain Nest applications, this is a good time to test the next packages, validate your tooling assumptions, and surface issues while the release is still taking shape.

You can follow the ongoing work and discussion in the v12 release PR.