What problem are you trying to solve?
You can't add an eve app to a next-forge monorepo and reuse its shared packages. next-forge puts import "server-only" in shared packages by default (packages/database, packages/auth, etc.), and eve chokes on that package in two of its three bundlers:
- Authored-module builds: tools are bundled and then evaluated with Node at build time. server-only either fails to resolve (pnpm strict layout) or gets inlined and throws its Next.js error. Either way eve build fails.
- The application bundle: even if the build is worked around, the Nitro output still contains a live import "server-only" — the build passes and the server crashes at boot.
The odd part: eve's workflow bundler already handles this. It has a PSEUDO_PACKAGES list (server-only, client-only, and Next's compiled variants) and stubs them out with empty modules. The other two bundlers just don't use it. Verified on eve@0.27.6.
Related: #1103 (same root cause via @clerk/nextjs), #1096.
Proposed solution
Use the existing PSEUDO_PACKAGES stub in the other two bundlers too. The plugin is already in the codebase.
Alternatives considered
No response
What problem are you trying to solve?
You can't add an eve app to a next-forge monorepo and reuse its shared packages. next-forge puts
import "server-only"in shared packages by default (packages/database, packages/auth, etc.), and eve chokes on that package in two of its three bundlers:The odd part: eve's workflow bundler already handles this. It has a PSEUDO_PACKAGES list (server-only, client-only, and Next's compiled variants) and stubs them out with empty modules. The other two bundlers just don't use it. Verified on eve@0.27.6.
Related: #1103 (same root cause via @clerk/nextjs), #1096.
Proposed solution
Use the existing PSEUDO_PACKAGES stub in the other two bundlers too. The plugin is already in the codebase.
Alternatives considered
No response