Bundlers: graph, runtime, chunks and dev servers

A bundler starts at an entry file and follows every import. For each one it must answer: which file does this string mean? The answer depends on rules that Node.js defined and bundlers follow, and on fields in each package's package.json.

• Relative specifiers (./App) try the path as written, then with each configured extension, then as a folder with an index file. Bare specifiers (react) are looked up in node_modules, in the importer's folder and then each parent.
• A package's "exports" map is the public API: subpaths it doesn't list can't be imported at all. Conditions inside it (browser, import, require, default…) are checked in the order they are written, and the first active one wins.
• Without exports, bundlers fall back to "browser", "module" and "main", in that order for the web. That is how one package ships an ES module build to bundlers and a CommonJS build to Node.
• The graph also records how each module is imported: statically, for side effects only (import "./analytics"), or dynamically with import(), which later starts a new chunk.

Browsers can load ES modules, but a bundle puts many modules in one file, so the bundler has to recreate what import does. webpack wraps each module in a function and adds a tiny runtime: a module registry, a cache, and a require function that runs a module the first time it's needed.

• Every module runs once. The second import of format.ts returns the cached exports, so its top-level code doesn't run again.
• Exports are getters (webpack's __webpack_require__.d), so importers always read the current value: ES module bindings are live. Real bundlers also call imported functions as (0, _format.formatPrice)(x), so this is not the module object.
• Imports run before the module's own code, depth first, in the order they are written. That order, and the logs in the demo, are the same as the browser's native module loader.
• In a cycle, one module has to run while the other is still unfinished. Reading its const then throws Cannot access 'a' before initialization. Function declarations are hoisted, so they survive cycles; constants don't.
• Production builds usually scope-hoist instead (Rollup, Rolldown, esbuild, webpack's ModuleConcatenationPlugin): ES modules are joined into one scope and the wrappers disappear, as in the optimize stage.

Tree shaking removes code nothing uses. It works because ES module imports are static: the bundler can see exactly which exports each module asks for, without running anything. What it can't know is whether top-level code that runs on import matters.

• An unused export is easy to drop. Top-level code such as registerIcon("cart", CartIcon) is harder: it might change global state, so a careful bundler keeps it, and with it the whole module.
• "sideEffects": false in a package's package.json promises that importing a module for nothing has no effect worth keeping, so whole modules can go. List files that do have effects, such as CSS: "sideEffects": ["*.css"].
• /*#__PURE__*/ before a call says the same about one call: if its result is unused, the call can be removed. Compilers add it to React.createElement and to enum objects for this reason.
• CommonJS (require, module.exports) is dynamic, so bundlers mostly can't tree-shake it. Prefer packages that publish ES modules.

Every import() is a split point: the module and what it imports go into a separate chunk that is downloaded only when that code runs. This is how routes, dialogs and heavy widgets stay out of the first download.

• The runtime remembers loaded chunks, so opening a page a second time costs nothing. The chunk names it needs are part of the runtime, which is why content hashes change when a lazy chunk does.
• A module used by two lazy chunks is either duplicated (downloaded twice, run once) or moved to a shared chunk that both load in parallel. Bundlers split shared code by default above a size threshold.
• Lazy chunks that import more lazy chunks create a waterfall: each download starts only after the previous one ran. Preload what you know will be needed (Next.js prefetches visible links' routes).
• In React, lazy(() => import("./Page")) plus <Suspense> uses this mechanism; Next.js splits every route automatically.

In development the goal changes from "small output" to "fast feedback". The three common designs differ in when they do the work: all up front, on request, or incrementally, with everything cached.

• Bundle first (webpack dev server): the whole app is bundled before the first page, so start-up grows with the app; afterwards rebuilds are incremental.
• Native ES modules (Vite): source is served unbundled and transformed when the browser requests each file, so start-up is nearly instant. Very large pages then make thousands of requests; dependencies are pre-bundled to keep that number down.
• Incremental bundling (Turbopack): bundle, but only what the requested route needs, and cache every step so an edit redoes almost nothing.
• Hot module replacement swaps an edited module in the running page. The update climbs through the modules that import it until one accepts it; with React Fast Refresh, a file that only exports components accepts and keeps its state. Reaching the top without one means a full reload.