CommonJS and ES Module Interoperability

CommonJS (CJS) and ES modules (ESM) use different module semantics, and interoperability can affect static analysis, tree shaking, and final bundle structure. Frontend build tools often support both, but mixed-module boundaries can reduce optimization opportunities or require special handling.

ESM uses `import` and `export` declarations that are statically recognizable, while CommonJS typically uses runtime-oriented constructs such as `require()` and `module.exports`. This difference matters because bundlers can analyze ESM dependency relationships before executing application code.

Tree shaking works most effectively when a bundler can determine which exports are used. ESM's static structure makes unused-export elimination straightforward in many cases, whereas dynamically computed CommonJS dependencies or exports can limit what the bundler can prove safely.

Interop behavior depends on the runtime and bundler. A CommonJS module imported from ESM may be represented through a default-like value, while named-import behavior can depend on static analysis performed by the toolchain. Conversely, loading ESM from CommonJS has additional constraints because native ESM loading is asynchronous in environments that support it through dynamic `import()`.

In a frontend build, converting or preserving module boundaries can change the generated chunks. A CommonJS dependency does not automatically make an entire application unoptimizable, but opaque module patterns can force conservative inclusion of code or prevent precise export analysis.

For interviews, distinguish language/module semantics from bundler behavior. `package.json` metadata, bundler configuration, transpilers, and the target runtime can all influence how CJS and ESM are resolved and transformed.

Key points

• ESM has statically analyzable `import`/`export` declarations; CommonJS commonly relies on runtime `require()` and `module.exports`.
• Static dependency information enables more reliable tree shaking and dead-code elimination.
• CJS-to-ESM and ESM-to-CJS interop semantics depend on the runtime and build tooling.
• Dynamic CommonJS patterns can reduce a bundler's ability to determine exactly which code is required.
• Module-format metadata such as package `type` and conditional exports can affect resolution.

Interview questions

Why does ESM generally enable better tree shaking than CommonJS?

ESM imports and exports have syntax that can be inspected without executing the module. A bundler can therefore construct a dependency and export-usage graph and identify bindings that are not needed. CommonJS can express dependencies and exports through runtime code, which may make that analysis incomplete. When the bundler cannot prove what is used, it may retain more code.

What happens when an ESM file imports a CommonJS package?

The exact interop representation is toolchain-dependent, but the CommonJS module is generally exposed to ESM code through an interop layer or default-like value. Some tools can infer named exports from CommonJS source, but such inference is not equivalent to ESM's declared named exports. A frontend bundler may transform the CommonJS module into a form compatible with the bundle. The important distinction is between language-level guarantees and bundler-specific compatibility behavior.

Why can CommonJS dependencies increase bundle size?

A bundler needs to determine which portions of a dependency are required. Straightforward CommonJS can sometimes be analyzed, but dynamic expressions or runtime-dependent export logic can prevent precise analysis. In those cases, the bundler may need to include a broader portion of the module than an equivalent statically analyzable ESM dependency. The resulting bundle can therefore contain code that could have been removed with clearer dependency information.

Can CommonJS and ESM be used in the same frontend project?

Yes, mixed module formats are common in modern build pipelines. The bundler must resolve each package according to its metadata and transform incompatible module syntax as needed for the target environment. The main concerns are resolution rules, interop semantics, static-analysis quality, and whether dependencies expose optimized ESM entry points. Package metadata such as conditional `exports` can determine which format the bundler receives.

How would you diagnose a bundle that contains unexpectedly large amounts of a CommonJS dependency?

I would first inspect the dependency graph with a bundle analyzer and identify which entry point and module format were resolved. Then I would check whether the package provides an ESM build and whether the bundler is actually selecting it. I would also look for dynamic `require()` calls, broad imports, side effects, and configuration that disables or limits optimization. Finally, I would verify the generated chunks rather than assuming the module format alone caused the size increase.