-
Notifications
You must be signed in to change notification settings - Fork 29.5k
Description
Link to the code that reproduces this issue
https://github.com/mikan3rd/nextjs-workspace-bug-reproduction
To Reproduce
- Create a pnpm workspace with a Next.js application (e.g., "main_app")
- Configure the Next.js app with output: 'standalone' in next.config.ts
- Run next build in "main_app" directory
- Check the generated standalone output directory
Current vs. Expected behavior
Current behavior:
The standalone build creates the server.js file at .next/standalone/main_app/server.js
This breaks existing deployment scripts and Docker configurations that expect the server.js file to be at the standard location.
Expected behavior:
The standalone build should create the server.js file at .next/standalone/server.js
as it did in previous versions
Provide environment information
Operating System:
Platform: darwin
Arch: arm64
Version: Darwin Kernel Version 24.6.0
Binaries:
Node: 22.13.0
pnpm: 10.15.1
Relevant Packages:
next: 15.5.3
typescript: 5.9.2
Next.js Config:
output: standalone
Which area(s) are affected? (Select all that apply)
Output
Which stage(s) are affected? (Select all that apply)
next build (local)
Additional context
This issue appears to be introduced in Next.js 15.5.0 and affects projects using:
- output: "standalone" configuration
- pnpm workspace environment
The issue causes the standalone build to include the package name in the output path structure, which breaks existing deployment configurations and scripts that expect the standard .next/standalone/server.js path.
This is particularly problematic for Docker deployments and CI/CD pipelines that rely on the predictable standalone output structure.
Workaround: Currently, users need to update their deployment scripts to account for the package name being included in the path, or modify their package.json name to avoid this issue.
Impact: This affects any project using standalone mode with pnpm workspaces, requiring changes to deployment configurations and potentially breaking existing Docker images and deployment scripts.