app deploy fails packaging @prisma/adapter-pg in a pnpm monorepo (ENOENT realpath /tmp/node_modules/...)

[luohoa97]

Summary

app deploy fails during local build packaging for a Next.js app in a pnpm monorepo that depends on @prisma/adapter-pg, with:

ENOENT: no such file or directory, realpath '/tmp/node_modules/.pnpm/@prisma+adapter-pg@7.8.0/node_modules/@prisma/adapter-pg'

Reproduced identically on 3.0.0-beta.28 (the latest npm tag) and 3.0.0-dev.129.1 (the newest available dev build as of 2026-07-17), via both bunx @prisma/cli@latest and a directly pnpm add-installed @prisma/cli binary (ruling out bunx caching as a cause).

Environment

• pnpm workspace monorepo, Next.js 16.2.10 (Turbopack) app as the deploy target
• App depends on @prisma/adapter-pg (driver adapter), marked in next.config.ts's serverExternalPackages (so Next does not bundle it — standard practice for native/runtime-only packages)
• Tested with pnpm's node-linker set to both hoisted and isolated — the exact failure differs by linker mode (see below), but a working deploy was never achieved in either mode
• pnpm run build (a plain, non-Compute-CLI invocation) succeeds fully in both linker modes once the app's own dependency graph is otherwise correct — this is specifically a prisma-cli app deploy packaging-step failure, not a Next.js build failure

Steps to reproduce (minimal shape)

1. A pnpm monorepo with node-linker=hoisted in .npmrc
2. An app package that depends on @prisma/adapter-pg, with next.config.ts's serverExternalPackages: ["@prisma/adapter-pg", "pg"]
3. prisma-cli project link <project-id> from the app directory
4. prisma-cli app deploy --project <project-id> --branch main --framework nextjs --yes

Observed behavior

• Under node-linker=hoisted: next build (run directly) succeeds. prisma-cli app deploy's local build step fails with ENOENT: no such file or directory, realpath '/tmp/node_modules/@prisma/adapter-pg' — a bare /tmp/node_modules/... path, one directory level shallower than where the actual staging appears to happen, suggesting an off-by-one in the temp-directory path used during artifact-symlink materialization.
• Under node-linker=isolated (the standard pnpm virtual-store layout): once the app's own build succeeds cleanly (confirmed via direct pnpm run build), app deploy fails with a more specific variant: ENOENT: no such file or directory, realpath '/tmp/node_modules/.pnpm/@prisma+adapter-pg@7.8.0/node_modules/@prisma/adapter-pg' — again missing the actual staging-directory path segment before node_modules.

What I ruled out

• bunx's own caching/wrapper behavior — reproduced identically via a directly pnpm add -D @prisma/cli-installed binary invoked without bunx at all.
• Turbopack/Next.js workspace-root inference — a separate, real issue was found and fixed on the app side (pinning turbopack.root), but the packaging-step failure above persists with or without that fix, in both linker modes.
• Missing/stale build artifacts in the monorepo — confirmed via a clean checkout in a separate git worktree, with dependencies freshly installed, that the app itself builds successfully; only app deploy's own post-build packaging step fails.

Trace

Error: ENOENT: no such file or directory, realpath '/tmp/node_modules/@prisma/adapter-pg'
    at Object.deployApp (file:///tmp/bunx-.../node_modules/@prisma/cli/dist/lib/app/app-provider.js:186:36)
    at async runSingleAppDeploy (file:///tmp/bunx-.../node_modules/@prisma/cli/dist/controllers/app.js:357:23)
    at async runCommand (file:///tmp/bunx-.../node_modules/@prisma/cli/dist/shell/command-runner.js:27:50)
    at async Command.<anonymous> (file:///tmp/bunx-.../node_modules/@prisma/cli/dist/commands/app/index.js:85:3)

Happy to provide more detail or a minimal reproduction repo if useful.