bun export condition points at the ESM build, breaking CJS require() under Bun

[jpr5]

The package's exports map (both 3.0.7 and current 4.1.0) is:

".": {
  "bun":     "./dist/index.js",
  "deno":    "./dist/index.js",
  "source":  "./src/index.ts",
  "import":  "./dist/index.js",
  "require": "./dist/index.cjs",
  "default": "./dist/index.js"
}

Bun resolves the bun condition before require. Since bun points at the ESM build (dist/index.js), a CommonJS consumer doing require("eventsource") under Bun gets the ESM module instead of the CJS one, and throws:

TypeError: require() async module ".../eventsource/dist/index.js" is unsupported. use "await import()" instead.

dist/index.cjs exists and is a correct CJS build, but the bun condition being checked first means require is never reached — the file is unreachable under Bun regardless of what a consumer does.

This affects both 3.0.7 and 4.1.0.

It also presents intermittently, which makes it easy to dismiss as flaky: this is a load-order race, not a probabilistic bug. If something earlier in the same process has already pulled in eventsource via the ESM graph, Bun's module cache may serve a later require("eventsource") synchronously from that already-resolved instance, and it succeeds. Whether it fails depends on which caller reaches the module first, not on anything random about eventsource itself.

Suggested fixes, either would resolve it:

• Point the bun condition at ./dist/index.cjs instead of the ESM build, or
• Drop the bun condition entirely and let Bun fall through to import (for ESM consumers) or require (for CJS consumers), same as Node's resolution.

Separately, I saw #349 is open and removes the CommonJS build entirely. If dist/index.cjs goes away, would a CJS require("eventsource") under Bun then resolve to the ESM build unconditionally? Is the intent that the ESM output no longer be requireable at all under Bun, or is there a reason the top-level-await/async-module shape of the ESM build wouldn't apply here? Just want to understand whether #349 is expected to close this out or make it more consistently reproducible.

[rexxars]

You're right that the bun condition wins over require, so require("eventsource") under Bun does load dist/index.js. But I don't think that's what's breaking for you, and I can't reproduce the error.

Bun can require() an ESM file. It only refuses when the file is an async module, meaning it has a top-level await. That's what the error message is about. eventsource has no top-level await in either 3.0.7 or 4.1.0. The only await sits inside a function body (the stream reader loop), and eventsource-parser has none at all.

Here's what I get with a plain require, on Bun 1.1.0, 1.2.0 and 1.3.4:

$ bun -e 'console.log(require.resolve("eventsource"))'
.../node_modules/eventsource/dist/index.js

$ cat test.cjs
const es = require("eventsource")
console.log("OK:", Object.keys(es))

$ bun test.cjs
OK: [ "ErrorEvent", "EventSource" ]

I also tried the load orders you mention: require first, dynamic import first, and require while an import() of the same module is still pending. All of them seem to work?

To double check the error itself, I made a stub package with the exact same exports map as eventsource, but with a top-level await in the ESM file. That fails right away, every time:

TypeError: require() async module ".../tlamod/index.js" is unsupported. use "await import()" instead.

So the error needs a top-level await somewhere. Something in your setup is supplying one, and it isn't this package.

On the two suggested fixes, I'd rather not do either:

Pointing bun at ./dist/index.cjs would break ESM users. The bun condition is matched for import too, not just require, so everyone on Bun would get the CJS build.

Dropping the bun condition brings back the dual package hazard, which is the reason the condition is there. I tested it by deleting bun from the installed package.json:

• with the bun condition: import and require give you the same EventSource class
• without it: two different classes, so instanceof checks quietly stop working

On #349: it should end this rather than lock it in. With only an ESM build left, every condition resolves to the same file, and requiring it works because it's a sync module. Node 22.19+ handles it, and Bun already does, as above. No top-level await gets introduced, so there's nothing for that error to fire on.

Could you share a bit more so I can dig in?

• your Bun version
• the full stack trace
• a minimal repro if you can manage one

[rexxars]

Again, I couldn't reproduce your issue - but now v5 is out which should reduce the amount of variations involved here - ESM only now.

[jpr5]

You're right that 3.0.7 and 4.1.x have no top-level await, and right that a plain require("eventsource") works. The ingredient I left out of the original report is that the failing graph reaches the module by both paths in the same run: a static ESM import "eventsource" and a CJS require("eventsource"). The bun condition collapses both onto dist/index.js, so the require lands on an ESM record Bun hasn't finished loading, and that is what it labels an "async module". A require-only graph — what you tested — never hits it.

Three files, nothing in the tree but eventsource:

mkdir es-bun-repro && cd es-bun-repro
bun add eventsource@3.0.7

cat > consumer.cjs <<'EOF'
const es = require("eventsource")
console.log("required OK:", Object.keys(es))
EOF

cat > cjs-only.mjs <<'EOF'
import "./consumer.cjs"
EOF

cat > both.mjs <<'EOF'
import "eventsource"
import "./consumer.cjs"
EOF

The two entrypoints differ by one line:

$ bun cjs-only.mjs
required OK: [ "ErrorEvent", "EventSource" ]

$ bun both.mjs
1 | const es = require("eventsource")
          ^
TypeError: require() async module ".../node_modules/eventsource/dist/index.js" is unsupported. use "await import()" instead.
      at <anonymous> (.../consumer.cjs:1:7)

Bun v1.3.14 (macOS arm64)

100/100 runs on 3.0.7, 100/100 on 4.1.1, 0/100 for cjs-only.mjs.

It is Bun-version-gated, which I think is why you couldn't reproduce it. Same repro, every 1.3.x release plus the two older ones you cited:

• 1.1.0, 1.2.0, 1.3.4, 1.3.5 ... 1.3.13 — passes, every run
• 1.3.14 (current release) — fails, every run

You tested 1.1.0, 1.2.0 and 1.3.4. All three are clean.

On the top-level await premise: it's separable. The graph above contains none — the only await in the tree is dist/index.js:94 inside the reader loop, and eventsource-parser has none, exactly as you said. Here is the same error from a package with no await anywhere at all:

mkdir -p noawait/node_modules/plain-esm && cd noawait
printf '{"name":"plain-esm","exports":{".":{"bun":"./index.js","import":"./index.js","default":"./index.js"}}}\n' > node_modules/plain-esm/package.json
{ echo 'export const hello = "hi"'; seq 200 | awk '{print "export function f" $1 "(a,b) { return a + b + " $1 " }"}'; } > node_modules/plain-esm/index.js
printf 'console.log("required OK:", require("plain-esm").hello)\n' > c.cjs
printf 'import "plain-esm"\nimport "./c.cjs"\n' > a.mjs
bun a.mjs

1 | console.log("required OK:", require("plain-esm").hello)
                ^
TypeError: require() async module ".../node_modules/plain-esm/index.js" is unsupported. use "await import()" instead.

grep -r await over that directory returns nothing. Shrink index.js back to just the export const and it passes. So on 1.3.14 "async module" means "Bun had not finished loading this ESM record when the require landed" — how much there is to load is part of it, and a top-level await is one way to get there rather than the only one.

Affects 3.0.7 and 4.1.1 identically. On 5.0.0 the same repro throws about 4 times in 100 instead of every time: the CJS build is gone so require always lands on the ESM file, but dist/index.js is now a small re-export barrel, which usually wins the race.

Fix is your call — your objections to both of my earlier suggestions were fair. Happy to file this as a fresh issue if you'd rather not reopen this one.

[jpr5]

@rexxars Sorry, I was off grid for a week. Only now was able to respond.

[rexxars]

No worries, thank you for getting back to me with details. I feel like this is a bun issue that they should fix, instead of having consumers work around it. Can't dedicate more resources to try and work around this, unfortunately.

[jpr5]

@rexxars Fair enough. I think I clocked at least 3 different Issues/Patches on bun for this, so it should be coming soon I'd hope. Cheers. 🍻