[Bug]: `require()` of a bundled ESM module returns a different object on each call

[sapphi-red]

Reproduction link or steps

https://repl.rolldown.rs/#eNp1T8sSgjAM/JVML+iMA/c6/IIHz15KCYITW+wDZRj+3RQUT96yye5mdxKNkJNAE9yY33yajZA/fBCaobbGB1BQgsNH7BzusrxAf2dGtj9ezHqv/t4vpijgZGvkBWilW/Qbcy+TcVmy3Lc2Ug0VQnAR80V1tkS1fRrQ0TmORSP0rjPBQ6PIJ1J6bglzstdd9rGS2eHrmv5zDRQymc48Lbm2pitae+Krty7AWmdQFJErTXNymFk5MIVUQB/E/AYZ32Vb

What is expected?

When bundled code require()s an ES module more than once, rolldown returns a different object on every call, violating Node.js CommonJS semantics where require() caches the module and returns the same object each time.

This is the rolldown equivalent of evanw/esbuild#4440.

a === b: true

Node.js caches by resolved module and returns the same namespace-backed object every time.

What is actually happening?

a === b: false

Rolldown inlines __toCommonJS(...) at each call site, and __toCommonJS allocates a fresh wrapper every time:

const a = (init_esm(), __toCommonJS(esm_exports));   // object #1
const b = (init_esm(), __toCommonJS(esm_exports));   // object #2  → a !== b

System Info

REPL 1.1.2

Any additional comments?

I've talked with LLM if there's an easy way to solve this, but didn't seem to:

Approaches considered

Approaches considered

What a fix has to satisfy

1. Identity — repeated require() of the same module returns the same object.
2. Cross-chunk — that identity holds even when caller and module land in different chunks.
3. Cycle-safe — a require() that fires during the module's own initialization (self-require or a require cycle) still gets a usable object, not undefined. Covered by bundler_esm_cjs_tests/16-19.
4. Clean namespace — the fix must not add observable properties to the module namespace object (the thing you get from import * as).
5. module.exports export — for export { x as 'module.exports' }, __toCommonJS returns that value by reference at call time, not via a live getter, so it can't be snapshotted before the body assigns it.
6. No WeakMap — WeakMap isn't guaranteed to be available in all target environments (old runtimes / constrained engines), so relying on it means either dropping those targets or carrying a typeof WeakMap fallback path. Avoiding it entirely keeps the output portable with no fallback branch.

The candidates

Starting from esbuild's fix, each WeakMap-free idea fails a different constraint:

• esbuild's __toCommonJSCached (#4441) — a WeakMap keyed on the namespace object; builds the wrapper on first call and caches it. Ships a typeof WeakMap fallback precisely because WeakMap may be unavailable.
  → Correct on everything except (6): the WeakMap dependency (and its fallback path) is the bar to clear without one.

• A — cache in a variable at the call site: (init(), x_cjs ??= __toCommonJS(x_exports)).
  → Fails (2): with code splitting each chunk declares its own x_cjs, so two chunks requiring the same module get two different objects.

• A′ — promote that cache var to a real per-module binding, exported from the owning chunk.
  → Correct, but the cache slot has to be writable across chunks, and rolldown's cross-chunk exports are getter-based (read-only). Needs new export-mechanism plumbing — the heaviest option.

• B — stash the cached object on the namespace object under a Symbol.
  → Fails (4): the slot shows up in Object.getOwnPropertySymbols(ns) / console.log(ns), since ns is the same object exposed via import * as.

• C1 — a separate memoized thunk: var x_cjs = __esmMin(() => (init(), __toCommonJS(x_exports))).
  → Fails (3): the memoized value isn't assigned until the thunk returns, so a re-entrant (cyclic) call gets undefined. Also needs a new cross-chunk symbol.

• C2 — fold the conversion into the init closure's return: init = __esmMin(() => { …body…; return __toCommonJS(ns) }), and lower each require to a bare init().
  → Gets (1), (2), (4), but still fails (3) for the same reason as C1 (the return value doesn't exist mid-body) — prototyping this regressed bundler_esm_cjs_tests/16-19 — and it entangles the change with TLA / concatenated closures.

A WeakMap-free candidate that clears all six: __toCommonJSInit eager-init wrapper

Wrap the init closure with a new runtime helper that computes and memoizes __toCommonJS(exports) before running the body:

__toCommonJSInit = (exports, fn, res, err) => () => {
  if (err) throw err[0];
  try { return fn && (res = __toCommonJS(exports), fn(fn = 0)), res; }
  catch (e) { throw err = [e], e; }
};
// init_x = __toCommonJSInit(x_exports, () => { …body… });
// require site → init_x()

• (1) Identity, (3) cycle-safe: res is set before the body runs, so a re-entrant require during init already sees the finished object; every later call returns the same res.
• (2) Cross-chunk: reuses the existing init_x symbol — no new cross-chunk binding. Consumer chunks import fewer symbols than before (just init_x, no longer x_exports + __toCommonJS).
• (4) Clean namespace: the cache lives in the closure, never on ns.
• (6): no WeakMap, so no fallback branch and no target restrictions.

[kb019]

Hi all,

I think the proposed __toCommonJSInit helper can be slightly refactored so it can handle the below cases.

Scenario 1: normal ESM module

For a module like this:

// entry.js

const a = require("./dep.js");
const b = require("./dep.js");
const c = require("./dep.js");
console.log(b);

// dep.js
export const a = 1;
Rolldown may output something like:

//it is here at the call site where we make decision to include dep_exports or not
init_dep();
const b=(init_dep(),__toCommonJS(dep_exports); 
init_dep()

As you observed from the above example it is at the call site we make decision whether to include exports or not, so a helper function like below might help

var __toCommonJSInitMin = (fn, resEx,resFn,err) => (exports) => {
  if (err) throw err[0];
  if(!exports){
    if(resFn) return resFn
  }else {
    if(resEx) return resEx;
  }
  try {
   //we should first call fn and then set the result, the reason for this is explained in scenario 2
    const fnResult = fn && (fn(fn = 0));
    if(!exports){
      return resFn = fnResult;
    }else{
      return resEx = __toCommonJS(exports);
    }

  } catch (e) {
    throw err = [e], e;
  }
};

So with this helper function we can include xxx_exports at the call site. So the expected output for the rolldown would be something like
below

var init_dep = __toCommonJSInitMin (()=>{
//....module body
})
init_dep();
const b=init_dep(dep_exports); 
init_dep()

Scenario 2: module.exports export

For a module like this:

// entry.js

const a = require("./dep.js");
const b = require("./dep.js");

console.log("a:", a);
console.log("b:", b);
console.log("same object:", a === b);

// dep.js

let api;

export { api as "module.exports" };

// some work happens first
console.log("dep is initializing...");

// assigned later
api = { ready: true };

here the order matters.

If we run:

res = __toCommonJS(exports);
fn(fn = 0);

then __toCommonJS(exports) may read api too early, before api = { ready: true } runs. In that case, the result can become undefined.

So for this case, it is better to run the module body first and then create the CommonJS wrapper:

So the final helper functions version can be like

var __toCommonJSInit = (fn, resEx,resFn,err) => (exports) => {
  if (err) throw err[0];
   if(!exports){
    if(resFn) return resFn
  }else {
    if(resEx) return resEx;
  }

  try {
     const fnResult = fn &&  ((0, fn[__getOwnPropNames(fn)[0]])((fn = 0)));
    if(!exports){
      return resFn = fnResult;
    }else{
      return resEx = __toCommonJS(exports);
    }
  } catch (e) {
    throw err = [e], e;
  }
};

var __toCommonJSInitMin = (fn, resEx,resFn,err) => (exports) => {
  if (err) throw err[0];
  if(!exports){
    if(resFn) return resFn
  }else {
    if(resEx) return resEx;
  }
  try {
 
    const fnResult = fn && (fn(fn = 0));
    if(!exports){
      return resFn = fnResult;
    }else{
      return resEx = __toCommonJS(exports);
    }

  } catch (e) {
    throw err = [e], e;
  }
};

This way, the module.exports value is read after the module has finished setting it, so the final result becomes { ready: true }

I would appreciate hearing your thoughts. Thank you.

[kb019]

@sapphi-red , @hyf0 , @IWANABETHATGUY , @shulaoda . Would really like to hear your thoughts on this please 🙏.
Would you like me to implement a draft it it becomes easy for you to review.

[sapphi-red]

I'm not sure if __toCommonJSInit makes sense or not in the first place. Maybe it is, but I haven't got time to verify.