facebook/react · error · Error

The module "${modulePath}" is marked as an async ESM module

Error message

The module "${modulePath}" is marked as an async ESM module but was loaded as a CJS proxy. This is probably a bug in the React Server Components bundler.

What it means

After resolving a client reference's manifest entry, the Turbopack server config cross-checks the module's async flag against the reference's $$async flag. Both being true means the manifest records the module as an async ESM module while the reference was created through the synchronous CJS-proxy path, which would make the client double-unwrap the module. React throws instead of emitting a payload the client cannot load correctly, and flags it as a React Server Components bundler bug.

Source

Thrown at packages/react-server-dom-turbopack/src/server/ReactFlightServerConfigTurbopackBundler.js:75

    // which contains this name as well.
    // TODO: It's unfortunate that we now have to parse this string. We should
    // probably go back to encoding path and name separately on the client reference.
    const idx = modulePath.lastIndexOf('#');
    if (idx !== -1) {
      name = modulePath.slice(idx + 1);
      resolvedModuleData = config[modulePath.slice(0, idx)];
    }
    if (!resolvedModuleData) {
      throw new Error(
        'Could not find the module "' +
          modulePath +
          '" in the React Client Manifest. ' +
          'This is probably a bug in the React Server Components bundler.',
      );
    }
  }
  if (resolvedModuleData.async === true && clientReference.$$async === true) {
    throw new Error(
      'The module "' +
        modulePath +
        '" is marked as an async ESM module but was loaded as a CJS proxy. ' +
        'This is probably a bug in the React Server Components bundler.',
    );
  }
  if (resolvedModuleData.async === true || clientReference.$$async === true) {
    return [resolvedModuleData.id, resolvedModuleData.chunks, name, 1];
  } else {
    return [resolvedModuleData.id, resolvedModuleData.chunks, name];
  }
}

export function getServerReferenceId<T>(
  config: ClientManifest,
  serverReference: ServerReference<T>,
): ServerReferenceId {
  return serverReference.$$id;

View on GitHub (pinned to eafeac097b)

Solutions

  1. Clear turbopack build caches and rebuild so async-module metadata is regenerated consistently.
  2. Import the client module the same way everywhere in the server graph (prefer static `import` over require/interop) so only one reference path is created.
  3. Align your framework/Turbopack version with the react-server-dom-turbopack build you depend on.
  4. If it persists on a clean build, minimize the repro (async ESM 'use client' module required through CJS) and report it to the React/Turbopack repository.
Defensive patterns

Strategy: try-catch

Try / catch

try {
  renderToPipeableStream(<App />, {})(res);
} catch (e) {
  if (/marked as an async ESM module but was loaded as a CJS proxy/.test(String(e.message))) {
    // bundler metadata inconsistency: rebuild from clean caches
    console.error('RSC bundler async-module mismatch - clear caches and rebuild');
  }
  throw e;
}

Prevention

When it happens

Trigger: resolveClientReferenceMetadata is called with a clientReference where clientReference.$$async === true and the manifest entry resolvedModuleData.async === true, i.e. an async ESM module reached the server through a require()/CJS interop path that also marked the reference async.

Common situations: A 'use client' module that is also an async ESM module (top-level await, await import cycles) required via CJS interop in the server graph; Turbopack/Next.js canary regressions in async-module tracking; mixed import styles (import vs require) of the same client module in one build.

Related errors


AI-assisted analysis of facebook/react@eafeac097b (2026-08-21). Data as JSON: /api/errors/75a39cd4b35faa9c. Report an issue: GitHub.