In a native ES module graph, main.js imports './a.js'; a.js starts with `import { fromB } from './b.js'` and then declares `export const fromA = 'A'`; b.js starts with `import { fromA } from './a.js'` and logs fromA at its top level. What happens when this runs, and why?

## The two phases that make this predictable An ES module is not loaded and run in one pass. The loader first constructs the graph (fetch and parse every module reachable from the entry), then **links** it, then **evaluates** it. Linking is the phase that matters here. Because `import` and `export` are static syntax, the engine knows every module's imports and exports without running a line of code. During linking it creates each module's environment and its bindings, and connects every import to the *binding* in the exporting module — not to a copied value. That is why `fromA` is a real, resolvable identifier inside `b.js` before anything has executed. Creating a binding is not the same as initializing it. A `const`, `let`, or `class` binding is created in an **uninitialized** state; reading it before the declaration executes is the temporal dead zone, and it throws `ReferenceError: Cannot access 'x' before initialization`. Only when the declaration statement actually runs does the binding become readable. ## Evaluation order in a cycle Evaluation is a depth-first walk from the entry module, and each module is evaluated *after* its dependencies. In a cycle that rule cannot be satisfied for both members, so the algorithm breaks the tie: when the walk reaches a module that is already on the stack (already being evaluated), it does not recurse — it skips that edge and continues. For `main.js → a.js → b.js → a.js`: 1. `main.js` begins; its dependency `a.js` is visited. 2. `a.js` begins; its dependency `b.js` is visited. 3. `b.js`'s dependency `a.js` is already in progress, so the edge is skipped. 4. **`b.js`'s body runs to completion first.** Its `console.log(fromA)` throws, because `a.js` has not executed its `const` declaration yet. If `b.js` had not read `fromA` at the top level, its body would finish, then `a.js`'s body would run, and `a.js`'s own read of `fromB` would see `'B'` — the deeper module finished, so its exports are complete. Cycles are only dangerous in one direction: the module that evaluates *first* is the one that can see an unfinished partner. ```js // b.js — evaluates first because of the cycle import { fromA } from './a.js'; console.log(fromA); // ReferenceError: Cannot access 'fromA' before initialization export const fromB = 'B'; ``` ## Which declaration forms survive the cycle Not every export behaves the same during linking: - **Function declarations** are hoisted *and initialized* when the module environment is set up, before evaluation. A cyclic partner can call an imported function declaration from its top level and it works. - **`var`** bindings are initialized to `undefined` at the same point, so reading one early yields `undefined` rather than throwing — quiet, and usually worse than the throw. - **`const`, `let`, and `class`** are uninitialized until their declaration executes, so an early read throws. `class` is a frequent victim: a cyclic `extends` evaluates the superclass expression at class-definition time and blows up immediately. ## Why the error moves when the entry point changes Evaluation order is decided by the walk, and the walk starts at the entry module. Make `b.js` the entry and the order flips: `a.js` evaluates first, its top-level read of `fromB` throws instead, and the module you "fixed" is now the broken one. This is why the same cycle can pass a focused unit test that imports one file and fail in the application, and why chasing the specific throwing line is the wrong instinct — the graph shape is the bug. ## The standard rescue Move the cross-import read out of module-body position. Imported bindings are live, so a function that reads `fromA` when it is *called* sees the initialized value, because by then both bodies have finished: ```js // b.js — no top-level read, so the cycle is inert at load time import { fromA } from './a.js'; export const describe = () => `from a: ${fromA}`; ``` That makes the program run, but it leaves the cycle in the graph and the next top-level read reintroduces the failure. The durable fix is to remove the loop — usually by extracting the value both modules need into a third module neither imports back.