chore(deps)(deps): Bump the nest-stack group across 1 directory with 4 updates

[dependabot]

Bumps the nest-stack group with 4 updates in the / directory: @nestjs/common, @nestjs/core, @nestjs/platform-express and zod.

Updates @nestjs/common from 11.2.3 to 12.0.1

Release notes

Sourced from @​nestjs/common's releases.

v12.0.0

NestJS v12.0.0

NestJS 12 is centered around ESM-ready packages, first-class Standard Schema support for validation and serialization, a rebuilt CLI, and native observability through the new @nestjs/observe SDK.

Existing CommonJS applications keep working — migrating your own code to ESM is entirely optional.

📖 Full migration guide

---

Upgrading

Upgrade the CLI first, since the upgrade command ships with it:

npm i -g @nestjs/cli@latest

Then, from the root of your project:

nest upgrade

nest upgrade moves every @nestjs/* package to its v12-compatible major at once and applies the mechanical parts of the migration for you — nest-cli.json webpack options, the GraphQL playground → graphiql rename and subscriptions transport swap, the NATS package replacement, @nestjs/config validation options, Jest and Joi bumps — then prints a report of everything it changed and everything you still need to review by hand. Run it with --dry-run first to see that report without touching your files.

It deliberately does not migrate your project to ESM, Vitest, or oxlint. Those are the defaults for newly generated projects; existing projects adopt them on their own schedule.

Node.js: v12 requires Node.js v20.19+ or v22.12+. Both require(esm) and the ESM packages depend on it; the upgrade command refuses to run on older releases (including the 21.x line). The latest active LTS is recommended.

---

Highlights

ESM packages

All core Nest packages now ship as ESM. Thanks to require(esm) in modern Node.js, most existing CommonJS applications continue to work without a rewrite. Review custom bootstrapping scripts, build tooling, and test runners if they assume CommonJS-only packages.

nest new now asks whether to scaffold a CommonJS or an ESM project.

Standard Schema validation

Route parameter decorators — @Body(), @Query(), @Param(), @RawBody() — accept a new schema option, designed for Standard Schema compatible libraries such as Zod, Valibot, and ArkType:

@Post()
create(@Body({ schema: createUserSchema }) body: CreateUserDto) {
  return this.usersService.create(body);
}
</tr></table> 

... (truncated)

Commits

• 4c751c5 chore(release): publish v12.0.1 release
• 6494a6c chore(release): publish v12.0.0 release
• e306724 fix(deps): update dependency file-type to v22
• edb0034 Merge branch 'master' into v12.0.0
• e255755 chore: resolve conflicts, minor fixes
• 5d1b19b Merge branch 'master' into v12.0.0
• a2c25c2 Merge pull request #17028 from OlegStrokan/feat/get-transport-server
• 5f2618a fix(common): Reject hex and non-numeric strings in parse-float pipe
• See full diff in compare view

Updates @nestjs/core from 11.2.3 to 12.0.1

Release notes

Sourced from @​nestjs/core's releases.

v12.0.0

NestJS v12.0.0

NestJS 12 is centered around ESM-ready packages, first-class Standard Schema support for validation and serialization, a rebuilt CLI, and native observability through the new @nestjs/observe SDK.

Existing CommonJS applications keep working — migrating your own code to ESM is entirely optional.

📖 Full migration guide

---

Upgrading

Upgrade the CLI first, since the upgrade command ships with it:

npm i -g @nestjs/cli@latest

Then, from the root of your project:

nest upgrade

nest upgrade moves every @nestjs/* package to its v12-compatible major at once and applies the mechanical parts of the migration for you — nest-cli.json webpack options, the GraphQL playground → graphiql rename and subscriptions transport swap, the NATS package replacement, @nestjs/config validation options, Jest and Joi bumps — then prints a report of everything it changed and everything you still need to review by hand. Run it with --dry-run first to see that report without touching your files.

It deliberately does not migrate your project to ESM, Vitest, or oxlint. Those are the defaults for newly generated projects; existing projects adopt them on their own schedule.

Node.js: v12 requires Node.js v20.19+ or v22.12+. Both require(esm) and the ESM packages depend on it; the upgrade command refuses to run on older releases (including the 21.x line). The latest active LTS is recommended.

---

Highlights

ESM packages

All core Nest packages now ship as ESM. Thanks to require(esm) in modern Node.js, most existing CommonJS applications continue to work without a rewrite. Review custom bootstrapping scripts, build tooling, and test runners if they assume CommonJS-only packages.

nest new now asks whether to scaffold a CommonJS or an ESM project.

Standard Schema validation

Route parameter decorators — @Body(), @Query(), @Param(), @RawBody() — accept a new schema option, designed for Standard Schema compatible libraries such as Zod, Valibot, and ArkType:

@Post()
create(@Body({ schema: createUserSchema }) body: CreateUserDto) {
  return this.usersService.create(body);
}
</tr></table> 

... (truncated)

Commits

• 4c751c5 chore(release): publish v12.0.1 release
• 3c25112 chore: update peer deps
• 6494a6c chore(release): publish v12.0.0 release
• c9d59f2 chore: expose missing internals
• 45485b5 fix(core): circular durable providers issue #17562
• f94e9eb fix(core): preserve middleware arity and harden instance decorator
• 1dcbc25 fix(core): instrument midldeware issue #17554
• f5bf4dd docs(core): update Mercure SSE header comment to current path
• edb0034 Merge branch 'master' into v12.0.0
• e255755 chore: resolve conflicts, minor fixes
• Additional commits viewable in compare view

Updates @nestjs/platform-express from 11.2.3 to 12.0.1

Release notes

Sourced from @​nestjs/platform-express's releases.

v12.0.0

NestJS v12.0.0

NestJS 12 is centered around ESM-ready packages, first-class Standard Schema support for validation and serialization, a rebuilt CLI, and native observability through the new @nestjs/observe SDK.

Existing CommonJS applications keep working — migrating your own code to ESM is entirely optional.

📖 Full migration guide

---

Upgrading

Upgrade the CLI first, since the upgrade command ships with it:

npm i -g @nestjs/cli@latest

Then, from the root of your project:

nest upgrade

nest upgrade moves every @nestjs/* package to its v12-compatible major at once and applies the mechanical parts of the migration for you — nest-cli.json webpack options, the GraphQL playground → graphiql rename and subscriptions transport swap, the NATS package replacement, @nestjs/config validation options, Jest and Joi bumps — then prints a report of everything it changed and everything you still need to review by hand. Run it with --dry-run first to see that report without touching your files.

It deliberately does not migrate your project to ESM, Vitest, or oxlint. Those are the defaults for newly generated projects; existing projects adopt them on their own schedule.

Node.js: v12 requires Node.js v20.19+ or v22.12+. Both require(esm) and the ESM packages depend on it; the upgrade command refuses to run on older releases (including the 21.x line). The latest active LTS is recommended.

---

Highlights

ESM packages

All core Nest packages now ship as ESM. Thanks to require(esm) in modern Node.js, most existing CommonJS applications continue to work without a rewrite. Review custom bootstrapping scripts, build tooling, and test runners if they assume CommonJS-only packages.

nest new now asks whether to scaffold a CommonJS or an ESM project.

Standard Schema validation

Route parameter decorators — @Body(), @Query(), @Param(), @RawBody() — accept a new schema option, designed for Standard Schema compatible libraries such as Zod, Valibot, and ArkType:

@Post()
create(@Body({ schema: createUserSchema }) body: CreateUserDto) {
  return this.usersService.create(body);
}
</tr></table> 

... (truncated)

Commits

• 4c751c5 chore(release): publish v12.0.1 release
• 3c25112 chore: update peer deps
• 6494a6c chore(release): publish v12.0.0 release
• e03cf5c fix(express,fastify): apply falsy status codes in reply()
• edb0034 Merge branch 'master' into v12.0.0
• e255755 chore: resolve conflicts, minor fixes
• 5d1b19b Merge branch 'master' into v12.0.0
• 043e951 fix(platform-express): address body parser review comments
• 361ce5f feat: narrow body parser options to the selected parser
• 68dfc23 Merge branch 'master' into v12.0.0
• Additional commits viewable in compare view

Updates zod from 4.4.3 to 4.6.0

Release notes

Sourced from zod's releases.

v4.6.0

Zod 4.6 is now available.

npm install zod@latest

At a glance:

• .validate() — checks input validity without building a result (up to 35x faster than .safeParse().success on a compiled schema)
• z.instanceof().properties() — validates properties of an instance
• fromJSONSchema() — enforces six validation keywords it used to ignore
• z.iban() — electronic-format IBAN plus mod-97 checksum
• z.withParser() — installs a parser generated elsewhere, for environments without new Function
• Faster CommonJS — drops the getter on every export (~3x faster z.validate() under require)
• Memory retention in recursive schemas — releases the parsed input, fixing a 4.5 out-of-memory regression
• @zod/mini — Zod Mini as a standalone package, versioned in lockstep with zod since 4.5

.validate()

Standalone boolean validation, in Zod, Zod Mini, and Zod Core. It answers "is this input valid?" without constructing a ZodError, which makes rejection cheap. The return type is a guard on the schema's input type.

z.validate(z.string(), "hi"); // true
z.validate(z.string(), 42);   // false

It is a method on Zod Classic schemas too. (#6547)

const Player = z.object({
  username: z.string(),
  xp: z.number(),
});
if (Player.validate(data)) {
data.username; // narrowed
}

In conjunction with z.compile(), this can be up to 35x faster than .safeParse().success on invalid input.

Time per call on invalid input, compiled with z.compile() — lower is better (benchmark)

Without compilation it is up to 5.9x faster. The saving is the result object: .safeParse() allocates one with an accessor pair on every call, and .validate() allocates nothing.

... (truncated)

Commits

• 1c51cbe 4.6.0
• 661673a docs: make the 9thCO logo visible on the light theme
• 6de10dc docs: reconcile the sponsor listings against every active sponsorship (#6579)
• 213ee75 feat(compile): add z.withParser for externally generated parsers (#6575)
• f9465d4 docs: reconcile the sponsor listings with active sponsorships (#6576)
• f7fd554 perf(v4): drop the lookaheads from the email regex (#6573)
• 36f1796 fix(v4): stop the memoizer from pinning a finished parse (#6572)
• 22bed61 feat(v4): add z.iban() string format with mod-97 checksum (#6571)
• c5b9bcb bench: measure what a runtime island's leaked indent cost the generated source
• e54716c docs(ecosystem): add @​apical-ts/craft (#5946)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[dependabot]

Looks like these dependencies are updatable in another way, so this is no longer needed.