How JavaScript Modules Work: The Circular Dependency That Broke Production

Imports are live bindings, not copied values

ES modules link a module graph before executing module bodies. An imported binding reflects the exporting module's binding; it is not a snapshot copied at import time. This structure enables static analysis, which is why bundlers can remove unused exports more reliably from ESM than from dynamic CommonJS patterns.

// counter.js
export let count = 0;
export function increment() { count += 1; }

// view.js
import { count, increment } from "./counter.js";
increment();
console.log(count); // 1

What cycles change

A cycle means A imports B while B eventually imports A. The modules can be linked, but one may attempt to read a binding before its exporting module initialized it. The resulting error can look mysterious because the import statements themselves are valid.

Cycles often reveal a design problem: a shared utility started importing a feature, while that feature still imported the utility.

// a.js
import { valueB } from "./b.js";
export const valueA = valueB + 1;

// b.js
import { valueA } from "./a.js";
export const valueB = valueA + 1; // initialized too early

Fix the graph, not the symptom

Extract shared types or pure helpers into a third module with no feature imports. In some cases, invert the dependency by passing a collaborator into a function. Dynamic import can delay a feature boundary, but it should not be used merely to conceal a tangled graph.

Use tooling to inspect the dependency graph when a cycle appears. Then decide which direction makes architectural sense.

What this means for bundles

Static ESM imports make tree shaking and route-level code splitting possible, but neither is magic. A barrel file can pull in side effects. A large module imported by a shared layout can become part of every route. Analyze a production bundle before guessing where bytes came from.