Tree Shaking: Shipping Only the Code You Use

WHY IT EXISTS: Modern apps consume large libraries, like component libraries, but often only use a small fraction of their code. Shipping the entire library to the user is inefficient, increasing bundle size and slowing down page loads. Tree shaking was created to solve this by including only the code that is actually used.

THE MENTAL MODEL: Imagine your component library is a massive toolbox. Without tree shaking, when you need a single screwdriver (a Button component), you have to carry the entire toolbox. Tree shaking analyzes your project, sees you only asked for the screwdriver, and hands you just that, leaving the hammers and wrenches behind. It works by statically analyzing ES Module import and export statements to determine what's unreachable.

HOW IT WORKS: The process relies on static code analysis. First, a bundler like webpack or Rollup builds a dependency graph of all import and export statements, starting from your application's entry point. Any exported code from a library that is never imported by your application is marked as "dead code". During the final minification step, this dead code is completely removed from the bundle. For this to work effectively, library authors must correctly configure the sideEffects flag in their package.json.

WHEN TO USE IT: Always enable tree shaking in production builds, especially when consuming large, modular libraries like Lodash, date-fns, or any modern component library (e.g., Material-UI, Ant Design). It is a fundamental optimization for keeping application bundle sizes small and improving load performance. It's not a feature you turn on for specific cases; it's a standard part of a modern production build process.

WHEN NOT TO USE IT: You don't disable tree shaking, but you must carefully manage files with side effects. A side effect is any code that affects the shared environment when imported, like import './styles.css' which injects global CSS, or a polyfill that modifies global prototypes. If a library is incorrectly marked as "sideEffects": false in its package.json, these crucial imports can be dropped, breaking your app. The correct approach is to provide an array listing the files with side effects, like "sideEffects": ["*/.css"].

ONE CANONICAL EXAMPLE: A design system library, my-ui-kit, exports 50 components. Your app only needs one: import { Card } from 'my-ui-kit'. The library's package.json contains "sideEffects": false. When you build for production, your bundler sees that only Card is imported. It traces the Card component's dependencies and includes them, but the other 49 unused components (and their dependencies) are "shaken" from the final bundle, resulting in a much smaller file being sent to the user's browser.