Tree Shaking: Shipping Only the Code You Use

WHY IT EXISTS: Modern JavaScript development relies on importing modules from large libraries. You might only need one function from a library with hundreds, but without optimization, the entire library gets included in your final application bundle, bloating its size and slowing down load times for users.

THE MENTAL MODEL: Imagine you're packing for a trip and you need a specific recipe from a giant cookbook. Instead of packing the whole 500-page book, you just photocopy the one page you need. Tree shaking is that photocopier for your code. It analyzes your application, sees which "recipes" (functions, classes) you actually use, and throws away the rest of the "cookbook" (the library).

HOW IT WORKS: Tree shaking relies on the static structure of ES2015 module syntax (import and export). During the build process, a bundler like webpack starts at your application's entry points and builds a dependency graph of all the code that is reachable. Any exported code from a module that is never imported and used by another module is considered "dead code" and is not included in the final output bundle. This process is often combined with minification, which further removes unused code within the functions that are kept.

WHEN TO USE IT: Tree shaking is a standard practice in almost all modern web development. It's automatically enabled in production mode for most popular frameworks and bundlers (like Create React App, Next.js, and Vite). You rely on it whenever you want to produce the smallest possible bundle for your users, which is especially critical for performance on mobile devices or slow networks.

WHEN NOT TO USE IT: You disable or carefully configure tree shaking for files with "side effects." A side effect is any code that does something just by being imported, without being explicitly called. Common examples include polyfills that modify global objects (like window or Array.prototype), global CSS imports (import './styles.css'), or modules that register themselves with a central store. If you tell the bundler these files are side-effect-free, they will be incorrectly removed, breaking your application.

ONE CANONICAL EXAMPLE: In your package.json, you can provide a hint to the bundler. Setting "sideEffects": false tells webpack that no file in your project has side effects, allowing for maximum optimization. If you have specific files with side effects, like a global stylesheet, you list them: "sideEffects": ["./src/styles.css"]. This tells the bundler "shake everything, except for this file, which you must always include." Getting this configuration wrong is a common source of bugs in production builds.