In an ES module `main.js` you write `console.log('main start');` and then, on the line below it, `import './dep.js';` — and `dep.js` logs `'dep evaluated'` at its top level. Which line prints first, and what rule decides that?

## The answer `dep evaluated` prints first, then `main start`. Nothing about the physical position of the `import` line changes this. ## Why: modules are linked before they are run Loading an ES module happens in distinct phases. First the engine **parses** the entry module and, purely from its syntax, reads off the list of modules it depends on; it fetches and parses those, recursively, until the whole graph is known. Then it **links** the graph, creating each module's bindings and wiring every import to the export it refers to. Only then does **evaluation** begin — the phase in which top-level code actually runs. Because the graph is fully known before any code runs, the engine can evaluate it depth-first: to evaluate a module, first evaluate each of its dependencies (in the order their `import` declarations appear), then run the module's own body. A module's body therefore always runs *after* the bodies of everything it imports. ## Hoisting `import` declarations are hoisted to the top of the module in the same sense that they take effect before the body runs. Two observable consequences: ```js // main.js console.log('main start'); // runs second import { greet } from './dep.js'; // dep.js body already ran console.log(greet()); // works ``` First, code written physically above the import still runs after the dependency. Second, an imported binding is usable in code that appears above its `import` line — the binding was created during linking and, in a non-cyclic graph, already holds a value because the exporting module was evaluated first. (This is unlike `let`/`const`, which are unusable before their declaration in the same module body.) ## Ordering among several imports With multiple dependencies, declaration order decides: ```js // main.js import './a.js'; // a's body runs first import './b.js'; // then b's console.log('main'); // then this ``` Depth-first means a nested dependency goes even earlier: if `a.js` itself imports `shared.js`, the output is `shared`, `a`, `b`, `main`. And a module that several modules import is evaluated only once — later importers reuse the already-evaluated instance. ## The bug this causes The most common real-world trip-up is trying to configure something before importing the module that reads it: ```js // main.js — broken globalThis.API_BASE = 'https://example.com'; import './client.js'; // client.js reads API_BASE at its top level -> undefined ``` `client.js` is evaluated before the assignment ever runs, so it sees `undefined`. The same shape shows up with polyfills, logger setup, and feature flags. Fixes, in rough order of preference: 1. **Make the dependency real.** Put the setup in its own module and have `client.js` import it; now the graph, not line order, guarantees the ordering. 2. **Export a function instead of doing work at import time.** `client.js` exports `createClient(config)`, and `main.js` calls it after setting up. Module bodies that only declare things are immune to ordering questions entirely. 3. **Load on demand.** Where the decision genuinely has to happen at runtime, a module can be brought in later rather than as a static dependency. ## How to reason about it in an interview Say the rule in one line — "imports are hoisted, the graph is linked before evaluation, and dependencies are evaluated depth-first in declaration order" — then show that you know what it costs you: any correctness that depends on top-level statements running before an imported module is a bug waiting to happen, because the import always wins. One caveat worth naming: in a circular graph a module can be evaluated while a dependency is only partway through, so an imported binding can still be uninitialized. That is the exception that proves the rule — the ordering guarantee is exactly "dependencies first" for graphs without cycles.