[Bug]: Panic occurred at runtime.

System Info

System Information

System: OS: Windows 11 Pro CPU: Intel(R) Core(TM) i7-10510U CPU @ 1.80GHz (2.30 GHz)

Binaries:

• Node: 24.21.0
• npm: 11.19.0
• pnpm: 11.25.0
• @rspack/core: 2.2.3
• @rspack/cli: 2.2.3

Details

Details

nest start <app-name> --watch

command failed with this error message:

I'm using Nest v12.0.0

To get the full stack backtrace, set the env var RUST_BACKTRACE='full' and run it in a NestJS workspace like so:

$env:RUST_BACKTRACE='full'; nest start <app-name> --watch

thread 'tokio-N' (<pid>) panicked at <redacted>:0:0:
should be a path: ()
stack backtrace:
   0:     0x7ffd6eb9a23a - napi_register_module_v1
   1:     0x7ffd6d0d0f03 - <unknown>
   2:     0x7ffd6eb99992 - napi_register_module_v1
   3:     0x7ffd6eb99c4f - napi_register_module_v1
   4:     0x7ffd6eb9975b - napi_register_module_v1
   5:     0x7ffd6eba6c49 - napi_register_module_v1
   6:     0x7ffd6eba6bf9 - napi_register_module_v1
   7:     0x7ffd6eba7b6b - napi_register_module_v1
   8:     0x7ffd6f5abf9e - napi_register_module_v1
   9:     0x7ffd6f5ac350 - napi_register_module_v1
  10:     0x7ffd6e62e1dc - napi_register_module_v1
  11:     0x7ffd6e629e2e - napi_register_module_v1
  12:     0x7ffd6e5912a5 - napi_register_module_v1
  13:     0x7ffd6e624fbc - napi_register_module_v1
  14:     0x7ffd6e59e7c0 - napi_register_module_v1
  15:     0x7ffd6e593177 - napi_register_module_v1
  16:     0x7ffd6e624fbc - napi_register_module_v1
  17:     0x7ffd6e59e7c0 - napi_register_module_v1
  18:     0x7ffd6e593177 - napi_register_module_v1
  19:     0x7ffd6e58cf35 - napi_register_module_v1
  20:     0x7ffd6e5898e9 - napi_register_module_v1
  21:     0x7ffd6e57f424 - napi_register_module_v1
  22:     0x7ffd6e579fe0 - napi_register_module_v1
  23:     0x7ffd6ddf06b6 - napi_register_module_v1
  24:     0x7ffd6ddf034f - napi_register_module_v1
  25:     0x7ffd6dfa33f5 - napi_register_module_v1
  26:     0x7ffd6df3b70e - napi_register_module_v1
  27:     0x7ffd6df3bc8a - napi_register_module_v1
  28:     0x7ffd6f3e4b92 - napi_register_module_v1
  29:     0x7ffd6f3e9c0e - napi_register_module_v1
  30:     0x7ffd6f3e260a - napi_register_module_v1
  31:     0x7ffd6f3e2471 - napi_register_module_v1
  32:     0x7ffd6eb9f674 - napi_register_module_v1
  33:     0x7ffe2be0cd87 - BaseThreadInitThunk
  34:     0x7ffe2d58caec - RtlUserThreadStart

Reproduce link

No response

Reproduce Steps

Reproduce Steps

• Migrated an existing NestJS 11/CommonJS project to NestJS 12 via nest upgrade, which set compilerOptions.builder to Rspack in nest-cli.json automatically (webpack → Rspack is the default migration path for v12).
• Manually converted the project to full ESM afterward ("type": "module", tsconfig changes above) to support statically importing better-auth/@thallesp/nestjs-better-auth without dynamic-import workarounds.
• While iterating on a Better Auth integration, repeatedly ran pnpm prisma generate / pnpm prisma migrate dev — which deletes and rewrites the prisma/generated output directory — while nest start --watch was already running in another terminal.
• First panic appeared at that point, in watch mode, immediately after a Prisma regeneration.

What's been ruled out since (in testing order)

What hasn't been tested yet (flagged honestly — don't claim these as ruled out)

• config.cache = false — untested; current best theory is Rspack's persistent build-cache snapshot computation (which needs to determine "managed" vs. source directories) shares the same underlying path-resolution code as the watcher's root analyzer, and may be panicking there regardless of watch mode
• Downgrade to @rspack/[email protected] — untested; would confirm whether this is a 2.2.x-specific regression A minimal reproduction outside the pnpm monorepo (no symlinked node_modules, no path aliases, no ESM) — untested; would confirm whether pnpm's symlink-heavy structure is actually load-bearing for the bug, or a red herring.
• A minimal reproduction outside the pnpm monorepo (no symlinked node_modules, no path aliases, no ESM) — untested; would confirm whether pnpm's symlink-heavy structure is actually load-bearing for the bug, or a red herring

Location is always redacted (release binary, no debug symbols) — RUST_BACKTRACE=full was tried and only produces unsymbolicated napi_register_module_v1 frames, no useful source location. Thread name (tokio-1, tokio-3, tokio-4, tokio-7 across different runs) and the PIDs vary each run, consistent with a Tokio worker thread panicking during some async filesystem operation rather than anything deterministic about thread identity.