release: v12.0.0 major release (approx. Q3 2026) - #16391
Conversation
feat: standard schema validation pipe, and standard serializer, introduce internal export subpath
refactor: minor codebase tweaks
sample: migrate all samples to esm and vitest
refactor: migrate from mocha, chai, sinon to vitest
|
Any plans for TypeScript 7? |
@kraikov currently it is not possible to integrate as TS 7 lacks programmatic API which NestJS CLI relies on, it will be needed to wait till TS 7.1 lands with the new programmatic API support |
Hm, you could still use NestJS 12 with TS7, however, you won't be able to use the CLI, right? |
You can use |
Thanks. I'm actually looking to bootstrapping a new project. For swagger I can go with schema-first (zod) so not a problem there. |
|
Maybe can we use what Nx describe here https://nx.dev/docs/technologies/typescript/guides/typescript-7 |
feat(microservices): expose transport server getter
|
Can I start new projects using NestJS 12 now? |
|
Hey. Will we also support bullmq v6 anytime soon ? |
|
@vaskouk done |
|
please don't make us use .js imports, fingers crossed |
u better start already using it. a couple of days and u won't feel difference. p.s. i felt the same |
|
Hey, I am the author of Valibot and co-created Standard Schema. Great to see the new |
`useBodyParser<Options = NestExpressBodyParserOptions>()` never checked its options argument.
`Options` occurs only inside `Omit<Options, 'verify'>`, a non-inferrable position, so it always
fell back to its default, and that default carries a `[key: string]: unknown` index signature.
`keyof` on it is `string | number`, `Exclude<string | number, 'verify'>` removes nothing, and the
resulting `Pick<T, string | number>` collapses to bare index signatures. Every call therefore
accepted any key, any value type, and even `verify` (the single option the signature claims to
remove, and the one Nest reserves to capture `rawBody`).
Key the options off the `parser` argument instead. `NestExpressBodyParserOptionsMap` maps each
parser to the options object its Express factory accepts, derived from `express` itself so the two
cannot drift, and `NestExpressBodyParserType` is now `keyof` that map. The type parameter is
inferred from `parser`, a real inference site, so `useBodyParser('json', ...)` accepts only
`express.json` options and now rejects typos, wrong value types, options belonging to a different
parser, and `verify`.
This is a types-only change; no emitted JavaScript differs.
`NestExpressBodyParserOptions` is
deprecated rather than removed, and calls that pass no explicit type argument are unaffected.
BREAKING CHANGE: `useBodyParser` now takes the parser type as its first type argument.
Calls that
pass an explicit options type, such as `app.useBodyParser<OptionsUrlencoded>('urlencoded', {...})`, no longer compile.
Drop the type argument and let it be inferred from the parser argument.
…eBodyParser-express feat: narrow body parser options to the selected parser for Express
|
@AbbasSrour you could then ether use for https://www.typescriptlang.org/tsconfig/#moduleResolution |
|
Is there a reflection about making Fastify the default HTTP handler rather than Express? |
Resolves conflicts between the v12 ESM/vitest migration and master: - Ported the SseSignal/AbortController SSE feature into the ESM codebase (sse-signal.decorator, router-response-controller, router-execution-context, interceptors-consumer transformDeferred rewrite) - Converted master's chai/sinon/mocha test additions to vitest style - Kept v12 sample structure (oxlint/vitest) while adopting master's renovate dependency bumps - Regenerated package-lock.json Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
once v12 is released, i'll share an article link with the details here! |
20 participants
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
Description
Approximate release window: early Q3 2026
Overview
ESM migration
require(esm)support.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#requireCLI (ESM/CJS)
Testing stack changes
Linter
Website redesign
Minor breaking changes
Schema support in route decorators
@Body,@Query, etc.) will support a newschemaoption that accepts a Standard Schema–compatible object. https://standardschema.dev/)class-validator.PRs:
transformsignatures for improved type safety #16147isHttpErrorcheck stricter #14753Packages will soon (possibly in Q2) be released under the
nexttag to let everyone play with them before they make it to the officiallatesttag.Does this PR introduce a breaking change?
Other information