NestJS v12 Preview: ESM, Vitest, and the End of class-validator

NestJS v12 preview packages landed on npm in early June — try it now with npx @nestjs/cli@next new. The stable release is still Q3 2026, but the preview is already revealing something more interesting than the ESM headline: three pieces of ecosystem debt the framework has been carrying since v9, finally addressed in a single release.

ESM, Finally — and Less Painful Than You Feared

Every official NestJS package is moving from CommonJS to ESM in v12. Teams that have tried this migration manually know the friction: tooling gaps, jest config hell, interop errors at 11 PM. The reason NestJS held off this long is the same reason most frameworks did — until Node.js shipped require(esm), forcing existing CJS codebases to adopt ESM was churn without enough payoff.

That’s now resolved. Kamil Myśliwiec, the framework’s creator, put it plainly: require(esm) was “the missing piece that made the move to ESM practical” — without it, “the migration wouldn’t have made much sense.” With it, existing v11 projects can consume the new ESM packages without rewriting a line. The official v12 draft PR documents the full scope of the change.

The practical change for new projects: the CLI will now ask whether you want CJS or ESM at project creation. Pick ESM and you get the full v12 stack — Vitest, oxlint, Rspack, and Standard Schema support — out of the box. Pick CJS and you keep the existing defaults. No forced migration, no cliff edge.

Three Tools Replaced at Once

The toolchain swap is where v12 gets opinionated. Jest, ESLint, and Webpack are all being replaced in the new ESM project defaults:

• Jest → Vitest. NestJS’s own internal test suite has already been migrated (PR #16370). Vitest is ESM-native by design and uses OXC for TypeScript decorator support, so the painful Jest + ts-jest + ESM workaround chain is gone.
• ESLint → oxlint. Rust-powered linting, consistent with the broader movement toward Biome, oxc, and Turbopack. Faster feedback in CI without configuration sprawl.
• Webpack → Rspack. A drop-in replacement with meaningfully faster cold build times. The NestJS team’s assessment: “all the optimizations came for free and just simply works.” See the Rspack NestJS integration guide for details.

CJS projects keep Jest. There’s no forced migration on the testing or linting front — only greenfield ESM projects get the new defaults. That’s the right call: forcing teams to migrate test infrastructure alongside a major framework version is how you create incidents.

Standard Schema: The class-validator Exit

This is the change with the most day-to-day impact. In v12, all route decorators — @Body, @Query, @Param — accept a schema option that takes any Standard Schema-compatible library. That means Zod, Valibot, or ArkType, natively, without a wrapper package:

@Post()
create(@Body({ schema: z.object({ name: z.string(), email: z.string().email() }) }) dto) {
  // dto is typed and validated
}

The same capability extends to the serializer interceptor, covering both input validation and output serialization in one unified approach.

Why does this matter? class-validator is annotation-based and requires emitDecoratorMetadata — a TypeScript compiler flag that’s increasingly awkward with modern bundlers and incompatible with many standard tsconfig setups. The ecosystem response was a proliferation of wrapper packages: nestjs-zod, nestjs-valibot, nestjs-standard-schema. NestJS is collapsing all of that into a single, framework-level ValidationPipe. Developers maintaining a third-party Zod integration package can drop it.

class-validator isn’t removed in v12 — existing code keeps working. But this is the signal: if your team is still writing DTO classes with @IsString() decorators, v12 is the right moment to evaluate the migration path. The InfoQ coverage of the v12 roadmap has the full breakdown of what Standard Schema brings to the framework.

What to Do Before Q3

The stable release is Q3 2026 and the migration guide hasn’t been published yet, but the preview is already installable:

npx @nestjs/cli@next new my-app

For existing projects: no urgency to migrate until the stable release and migration guide drop. For new projects starting now: there’s no good reason to start on v11 defaults. Use the @next tag, pick ESM at the CLI prompt, and get the full v12 stack from day one.

v12 isn’t a dramatic overhaul — it’s NestJS catching up to where the JavaScript ecosystem has been for two years. The framework prioritized stability and enterprise compatibility, and the ESM transition was genuinely blocked on Node.js tooling until recently. The preview is out, the migration path is low-friction, and Q3 is close enough that teams should start thinking about it now rather than scrambling when stable drops.