chore(deps): update vitest monorepo to ^4.1.11

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
@vitest/coverage-v8 (source)	^4.1.7 → ^4.1.11
vitest (source)	^4.1.7 → ^4.1.11

---

Release Notes

vitest-dev/vitest (@​vitest/coverage-v8)

v4.1.11

Compare Source

   🐞 Bug Fixes

• Revive global concurrency limit for test lifecycle [backport to v4]  -  by @​sheremet-va and @​hi-ogawa in #​10992 (5146d)
• browser:
  • Encode iframeId in tester iframe URL [backport to v4]  -  by @​sheremet-va, Pduhard and Claude Opus 4.8 in #​10955 (10b2c)
  • Trigger playwright/chromium gc on lower disk availability [backport to v4]  -  by @​hi-ogawa, Hiroshi Ogawa and OpenCode in #​10951 (9851d)
• mocker:
  • Restrict redirect mocks to the fs allowlist [backport to v4]  -  by @​sheremet-va in #​10974 (fe5a1)

    View changes on GitHub

---

Configuration

📅 Schedule: (in timezone America/New_York)

• Branch creation
  • "before 4am on monday"
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[underfisk]

@copilot can you investigate the failing tests? Is it related to drift on the nestjs versions between the dev dependencies/integration tests? It's a known DI issue if Nestjs has different versions especially around testing

[Copilot]

@copilot can you investigate the failing tests? Is it related to drift on the nestjs versions between the dev dependencies/integration tests? It's a known DI issue if Nestjs has different versions esp...

I investigated this locally and it doesn’t look like NestJS version drift.

Findings:

• pnpm why @nestjs/core shows a single installed version (11.1.24) and @nestjs/testing is also 11.1.24.
• The same DI failure reproduces on the commit before this Renovate bump (af1c8d7) with Vitest 4.1.7, so it’s not introduced by 4.1.10.
• The first real failure is Nest can't resolve dependencies of the DiscoveryService (?, MetadataScanner) (missing ModulesContainer), and the Stripe failures are mostly cascades from app bootstrap failing.

So this appears to be an existing Nest testing/Discovery wiring issue in this branch baseline, not a version mismatch between dev deps/integration tests caused by this dependency update.

[underfisk]

@copilot can you investigate the failing tests? Is it related to drift on the nestjs versions between the dev dependencies/integration tests? It's a known DI issue if Nestjs has different versions esp...

I investigated this locally and it doesn’t look like NestJS version drift.

Findings:

• pnpm why @nestjs/core shows a single installed version (11.1.24) and @nestjs/testing is also 11.1.24.
• The same DI failure reproduces on the commit before this Renovate bump (af1c8d7) with Vitest 4.1.7, so it’s not introduced by 4.1.10.
• The first real failure is Nest can't resolve dependencies of the DiscoveryService (?, MetadataScanner) (missing ModulesContainer), and the Stripe failures are mostly cascades from app bootstrap failing.

So this appears to be an existing Nest testing/Discovery wiring issue in this branch baseline, not a version mismatch between dev deps/integration tests caused by this dependency update.

Could you address this in a PR?

[Copilot]

@copilot can you investigate the failing tests? Is it related to drift on the nestjs versions between the dev dependencies/integration tests? It's a known DI issue if Nestjs has different versions...

I dug into it, but a safe fix here is bigger than this dependency PR. The DI failure is in @golevelup/nestjs-discovery requiring Nest internals (ModulesContainer) during test module bootstrap, and the Stripe failures are downstream of that bootstrap failure.

I can put up a follow-up PR that updates discovery test/bootstrap wiring for Nest 11 (and adjusts affected Stripe tests) as a dedicated fix. If you want, I’ll proceed with that approach.

[underfisk]

@copilot can you investigate the failing tests? Is it related to drift on the nestjs versions between the dev dependencies/integration tests? It's a known DI issue if Nestjs has different versions...

I dug into it, but a safe fix here is bigger than this dependency PR. The DI failure is in @golevelup/nestjs-discovery requiring Nest internals (ModulesContainer) during test module bootstrap, and the Stripe failures are downstream of that bootstrap failure.

I can put up a follow-up PR that updates discovery test/bootstrap wiring for Nest 11 (and adjusts affected Stripe tests) as a dedicated fix. If you want, I’ll proceed with that approach.

Please do, proceed

[Copilot]

@underfisk I've opened a new pull request, #1253, to work on those changes. Once the pull request is ready, I'll request review from you.

[underfisk]

@copilot Can you run "pnpm install" to force regenerating the lock file properly?

[Copilot]

@copilot Can you run "pnpm install" to force regenerating the lock file properly?

Ran pnpm install on branch head (18089b0). pnpm-lock.yaml is already up to date, so the command produced no file changes and no new commit was needed.