Repository navigation
pg bundling isuses with nitro v3 and cloudflare #4010
Description
Describe the feature
While using Nitro, the current bundler has encountered many strange issues, such as:
-
WASM cannot extend beyond the project scope.
-
The runtime requires WASM, but it doesn't handle platform-compliant formats well.
-
External non-standard ESM dependencies (e.g., Prisma ORM, many of its dependencies are CJS, or pg packages, whose ESM support requires writing an ESM file that depends on internal CJS).
-
Non-standard Node module dependencies, such as
require("events").
These problems often occur with Cloudflare workers, and updating the current bundling configuration makes it difficult to handle various situations (usually occurring in other dependent packages).
Through testing, wrangler's built-in bundling handles all platform-compliant situations. For example, Hono is clever in that it doesn't handle bundling itself, so using Hono in the same situation works without problems.
For example, a recent problem I encountered involved needing to depend on Prisma ORM and then using the pg driver. Bundling was flawless, but deployment to Cloudflare failed.
Q: So, what is pure packaging mode support?
Simply put, Nitro doesn't handle any packaging; it simply writes the code from a virtual directory to a specific folder and provides an entry file. Alternatively, Nitro provides a virtual entry point (which the user imports and then re-exports).
This way, all code dependencies are located in the original TS/JS files and the pkg folder under node_modules.
Major Benefits
Cloudflare deployment will no longer be hindered; for example, features like cloudflare.exports.ts can be omitted.
Implementation Difficulty
Not yet investigated, but based on previous understanding of Nitro's internal packaging:
-
You still need to run
nitro build. -
Set
builderin nitro.config.ts to false to support pure packaging mode.
Additional information
- Would you be willing to help implement this feature?
Activity
pi0 commentedon Feb 8, 2026
Thanks for the writeup.
Nitro uses rollup, rolldown or vite for bundling production code and there might be bundling issues, so i appreciate any reproduction of the issues you are mentioning above.
(also please mention if you are using nitro v3 with rolldown or older nitropack v2 with rollup)
There is a new standard preset that writes just a fetch export handler woth no platform handling but i don’t suppose in larger projects, wrangler (esbuild) would handle dependencies better than rolldown. (also note that node polyfills in wrangler is based on unjs/unenv that nitro uses)
[-]Purified packaging mode support[/-][+](v3) Purified packaging mode support[/+]medz commentedon Feb 9, 2026
@pi0 Yes, Wrangler (esbuild) isn't as powerful as Vite/rolldown. However, for NPM packages with Cloudflare-compatible configurations, Wrangler is faster.
Indeed, Wrangler has made many rule optimizations for Cloudflare compatibility. I've only looked at one fetch preset, but I haven't verified it yet; I need to try it out. Because Nitro's greatest appeal is its filesystem routing.
medz commentedon Feb 9, 2026
This results in issues where, if
pgis used and Nitro v3 + Rolldown is used for packaging, the build process is successful, but deployment on Cloudflare fails.Verified:
medz commentedon Feb 9, 2026
I'll write a minimal, reproducible repository later ❤️
pi0 commentedon Feb 9, 2026
Thanks, lets investigate this 👍🏼
[-](v3) Purified packaging mode support[/-][+]`pg` bundling isuses with nitro v3 and cloudflare\[/+][-]`pg` bundling isuses with nitro v3 and cloudflare\[/-][+]`pg` bundling isuses with nitro v3 and cloudflare[/+]medz commentedon Feb 10, 2026
@pi0 I prepared a minimal reproduction repo for this issue: https://github.com/medz/nitro-issue-4010-pg-cloudflare-repro
It includes two script paths:
pnpm run repro:nitro:failnitro buildsucceeds, butwrangler dev --config .output/server/wrangler.jsonfails at worker startup with:Callingrequirefor "events" in an environment that doesn't expose therequirefunction.pnpm run repro:wrangler:okwrangler devruns directly fromserver.tsand responds with 200, andwrangler deploy --dry-runalso succeeds.So this looks isolated to the Nitro + rolldown bundling path, not direct Wrangler packaging.
medz commentedon Feb 10, 2026
@pi0 I prepared a second repo as an independent PoC for the issue-body idea:
https://github.com/medz/nitro-issue-4010-builder-false-prototype
This PoC validates the
builder: falseintent:Verification command:
pnpm run prototype:verifyWhat it checks:
prototype:buildgenerates.output/server/index.mjs+ virtual/runtime modules.wrangler devstarts successfully from generated output./api/pg(filesystem route) returns 200 and loadspg.wrangler deploy --dry-runsucceeds.So the proposal seems technically feasible and meaningful: preserve Nitro DX while delegating packaging compatibility to Wrangler.
medz commentedon Mar 20, 2026
I've released a new package to solve this problem 👉 https://github.com/medz/nitro-wrangler
Its sole purpose is to ignore user-intentioned code and let wrangler handle the code packaging. It's now officially in use and working great 🫡
pi0 commentedon Mar 20, 2026
There is no current issue with pg bundling BTW. Depending on multi phase building (esbuild) is not good for long term we should find and fix root cause issues with rolldown setup.
medz commentedon Mar 20, 2026
@pi0 Yes, the packaging is working fine. However, it's been moved to the runtime. This is more frustrating and harder to debug than a build failure.
This is just a temporary solution for Nitro to address the compatibility issues of mixed CJS/ESM packaging; please don't reject it outright. It will be archived once Nitro resolves these issues.
But we are currently experiencing these problems, and configuring these behaviors from Rolldown is extremely cumbersome (we've tried for a month without successfully handling edge cases in various dependencies).
I think we could create a new issue report from this, specifically regarding the compatibility regressions between dependencies like pg (which internally wraps CJS in ESM to disguise it as ESM) and worked.