Bundling & Tree Shaking

The plain-language idea

Bundling takes your app's real module graph — dozens or hundreds of separate files importing each other — and combines it into a small number of files optimized for the browser to download and parse, instead of making a separate network request per source file.

Tree shaking (dead-code elimination, specifically for ES Modules) is a bundling step that removes exports nothing in your app actually imports:

// utils.js
export function used() { return 1; }
export function neverImported() { return 2; }  // dropped entirely from the bundle

// app.js
import { used } from "./utils.js";

If nothing imports neverImported, a tree-shaking-capable bundler removes it from the final output entirely — the bundle only contains code that's actually reachable from your app's real entry point.

Ten separate files, ten separate network requests — slow, especially over older HTTP.

BackNext

What people usually miss

Watch out

• A function or module with a side effect can't be safely tree-shaken, even if its exports are unused — if importing a file runs code that does something observable (registers a global, mutates a shared object), removing it could change behavior, so bundlers conservatively keep it unless explicitly marked "sideEffects": false in package.json.
• Importing one named export from a library doesn't guarantee only that code ships — if the library isn't authored in a tree-shakeable way (deeply nested re-exports, CommonJS internals), import { debounce } from "big-lib" can still pull in the whole library.
• Code splitting (the React lazy-loading lesson) and tree shaking are different, complementary optimizations — tree shaking removes code that's never used anywhere; code splitting defers code that's genuinely used, but not on the very first screen, into a separate chunk loaded later.

Why this matters in interviews

"Why does your app's bundle include code you're pretty sure you're not using?" is a real, practical debugging question, and understanding tree shaking's actual requirements (ESM, no unexpected side effects, a tree-shakeable library build) is what lets you diagnose it instead of just re-running the build and hoping.