Node "Dynamic require of X is not supported" in Bundled ESM in CI - Fix the Bundle

By Daniel Zoghalchali·Latchkey

When a bundler emits ESM, runtime require() is not available, so any require call that survives bundling throws "Dynamic require of X is not supported".

What this error means

A bundled output run in CI throws Error: Dynamic require of "<name>" is not supported, from a dependency that still calls require() at runtime under the ESM bundle.

Error: Dynamic require of "fs" is not supported
    at file:///home/runner/work/app/app/dist/index.mjs:12:9
    at node_modules/some-cjs-dep/index.js

Diagnose it: the shell in CI is not your shell

Package scripts run under a different shell, a different PATH, and a non-interactive environment on a runner. Most scripts that fail only in CI are relying on something the login shell gave them locally: a tool on PATH, an environment variable from a dotfile, or a TTY.

# what the script can actually see
npm run env | grep -E "^(PATH|NODE_ENV|CI)=" 

# is the binary on PATH for the script, not just for you?
npm exec -- which <tool> || echo "not resolvable from npm scripts"

# run the exact script with tracing
sh -x -c "$(node -p "require('./package.json').scripts.build")"

Common causes

A CommonJS dependency using runtime require in an ESM bundle

The bundler produced ESM, but a bundled CommonJS module calls require() at runtime, which the ESM output cannot satisfy.

Conditional or dynamic require inlined into the bundle

A require behind a condition was inlined instead of externalized, so it runs in the ESM context.

How to fix it

Mark the dependency external

1. Keep the CommonJS dependency external so it loads from node_modules at runtime.
2. Ship node_modules alongside the bundle.

// esbuild
external: ['some-cjs-dep']

Target a CommonJS bundle format

1. Bundle to CommonJS so runtime require is available.
2. Re-run the output with node.

esbuild src/index.ts --bundle --platform=node --format=cjs --outfile=dist/index.js

Make failures fail the job

A multi-command script can report success while a middle command failed, which produces the worst kind of CI result: a green build that shipped something broken.

# pipefail is NOT set by default in every runner shell
- name: Build
  shell: bash
  run: |
    set -euo pipefail
    npm run build | tee build.log

How to prevent it

• Choose the bundle format that matches how dependencies load, externalize Node built-ins and CommonJS-only packages, and test the bundled artifact in CI before relying on it.

Frequently asked questions

Related guides

References

• Node.js documentation
• npm CLI documentation
• GitHub Actions documentation