Environment

Reproduction

https://stackblitz.com/edit/github-7o3sknxd
(the stackbiltz doesn't work, it's pinned to pnpm 8 for some reason)

1. Initialize a Nuxt 5 project using pnpm (default configuration).
2. Create any server file (e.g., server/api/test.ts or a server plugin) that imports from nitro or h3 (e.g., import { useRuntimeConfig } from 'nitro/runtime-config', import { defineHandler } from 'h3').
3. Attempt to build or start the dev server: compilation fails with unresolved imports.
4. Add nitro/h3 to the project's dependencies/devDependencies to resolve the import.
5. Run the dev server: the imports resolve, but runtime features like virtual modules/configs break due to the duplicate package instance.

Describe the bug

Nuxt 5 server-side code (plugins, routes, middleware) fails to resolve imports from nitro or h3 (including direct imports like h3's defineHandler or Nitro auto-imports) when using pnpm's default isolated (shamefully-hoist=false) layout.

If a user adds nitro or h3 to their project's package.json to fix the resolution error, pnpm installs a duplicate peer-resolved instance. This duplicate package bypasses Nitro's builder/plugin context, triggering virtual module stub warnings (e.g., Nitro runtime imports detected without a builder or Nitro plugin. A stub implementation will be used.) and breaking features like useRuntimeConfig().

Additional context

Currently, the only working setup with pnpm is forcing shamefully-hoist=true and not having nitro/h3 in package.json.

Since Nuxt 5/Nitro 3 expects user code to import/use symbols from nitro and h3, either @nuxt/nitro-server declares them as peerDependencies, or Nuxt should re-export them to support strict package manager layouts.

Logs