Nitro v3 alpha 2 breaks CommonJS packages with Bare runtime detection (end-of-stream, duplexify)

[WebCloud]

Environment

• nitro: 3.0.1-alpha.2
• Runtime: Bun 1.3.5
• Framework: TanStack Start
• Affected packages: end-of-stream@1.4.5, duplexify@4.1.3 (via @google-cloud/*)

Reproduction

1. Create a TanStack Start app with @google-cloud/storage or @google-cloud/monitoring dependency (these pull in duplexify → end-of-stream)
2. Use nitro@3.0.1-alpha.2 with nitro/vite plugin as recommended by the hosting guide
3. Build and run: bun run .output/server/index.mjs

Now, this was actually working fine before this alpha.2, and it seemed fine until it just started crashing, seemingly out of nowhere after a few runs of some workflows in my app.

Describe the bug

After upgrading to nitro@3.0.1-alpha.2, server builds crash at runtime with:

TypeError: undefined is not an object (evaluating 'commonjsGlobal.Bare')
at requireEndOfStream (/app/.output/server/_libs/end-of-stream.mjs:11:13)
at requireDuplexify (/app/.output/server/_libs/duplexify.mjs:11:32)

Additional context

The end-of-stream@1.4.5 package has Bare runtime detection:
var qnt = global.Bare ? queueMicrotask : process.nextTick.bind(process);

Logs

TypeError: undefined is not an object (evaluating 'commonjsGlobal.Bare')
        at requireEndOfStream (/app/.output/server/_libs/end-of-stream.mjs:11:13)
        at requireDuplexify (/app/.output/server/_libs/duplexify.mjs:11:32)

  11 |   var qnt = commonjsGlobal.Bare ? queueMicrotask : process.nextTick.bind(process);

  error: undefined is not an object (evaluating 'commonjsGlobal.Bare')

[pi0]

Which version of vite are you using (if 7, i suggest to try migrating to vite@beta, rolldown CJS handling is usually better)

[WebCloud]

I see, good point, I'll try with beta, I am on v7. I'll report back once I have a build deployed

[elyobo]

Similar looking issue for me with Winston; seemed to be the inlining. Adding winston to the new traceDeps option solved the problem for me - adding duplexify or end-of-stream might work for you.

I do get an incedible number of (apparently harmless?) complaints of a Module level directives cause errors when bundled, "use client" nature with the upgrade though.

Switching to vite@beta is blocked by vitejs/vite#21466 for me at the moment, although that's already fixed so will hopefully be an option shortly.

[elyobo]

I've ran into further issues once actually trying to deploy to production, which then switches to @google-cloud/logging-winston as a transport layer. That had to be traced as well, but then further issues arose - which parts of the package are copied into the output has changed, e.g. uuid previously brought in the dist dir and files (not subdirectories) within it but the updated version brings in dist/esm-node and the files in there - which cannot be resolved at runtime.

Rolling back the upgrade (which is a shame, it fixes a developmemnt mode problem rendering not found routes) and will check back on the next release.

[elyobo]

vite beta 10 is out with the fix from vitejs/vite#21466 and now traceDeps is sufficient - I don't think the latest nitro alpha is compatible with vite 7, needs the beta.

Edit: seems like the behaviour is inconsistent, it was working and then now not - possibly due to cached output, unsure, but still having random module resolution with the bundling.

Tried just tracing all deps but still no go.

Cannot find module 'nitro/vite/runtime'

[WebCloud]

@pi0 just updatting that with latest vite beta (beta 10) and lates Nitro alpha 2 we are looking good.

The error has not presented itself.

[productdevbook]

nitro: {
    experimental: {
      tsconfigPaths: true,
}
}

[pi0]

@productdevbook If you are using nuxt (dev branch) nuxt generates invalid tsconfig aliases thats why enabling flag breaks it. Latest vite/rolldown natively supports tsconfigPaths (see rc.2 release notes). Otherwise new issue with reproduction please as always.