Tree Shaking and Dead Code

## The situation, stated precisely You wrote one import line for one function. The production bundle for that entry got tens of kilobytes bigger. Tree shaking — the build step that drops code nothing can reach — is switched on. Nothing is broken, and nothing is misconfigured. The bundle is telling you something true about the package you just adopted. The mental model that fails here is "tree shaking removes what I don't use." The accurate model is narrower: a build can only remove code it can *prove* is unreachable. Proof requires a statically analysable module graph — imports and exports that are fixed at build time. Where the graph is opaque, the build keeps everything, because keeping working code is always the safe choice and dropping reachable code would break the app. ## Step one is attribution, not a fix Before changing anything, find out which module owns the bytes. Every serious build can emit a report of what ended up in each output file, and the answer to "why did my bundle grow" is usually one line of that report. Attribute first, because the same 70 kB symptom has several different causes and the remedy depends on which one you have: - the package ships a non-shakeable distribution (the lodash case); - you imported through an aggregating entry point that pulls in far more than the one function you wanted; - the helper you imported transitively depends on something large — a date library, a polyfill, an internationalisation table; - you now have two copies of the same library at different versions, one from your import and one from a transitive dependency. Guessing between these wastes a day. Reading the output takes a minute. ## Which distribution are you consuming For lodash specifically, the package published as `lodash` is a CommonJS build whose modules reference each other through shared internals. A CommonJS module's exports are an object assembled at runtime, so a build tool cannot generally decide that only one property of it is ever read. The result is that `import { debounce } from 'lodash'` and `const _ = require('lodash')` cost roughly the same. The same library also publishes `lodash-es`, an ES-module build of the same functions. ES modules declare their imports and exports statically, which is the precondition that makes elimination possible in the first place. Packages also carry a `sideEffects` field in package.json that further influences what a build dares to drop — but no field rescues you when the module format itself is opaque. The practical habit: before adopting a dependency, look at what it publishes. A package that ships an ES-module build, keeps its functions in separate modules, and has few transitive dependencies will cost you close to what you use. A package that ships one monolithic CommonJS file will cost you all of it, forever, no matter how disciplined your import lines are. ## The remedies, cheapest first ```javascript // Whole CommonJS build lands in the bundle import { debounce } from 'lodash'; // Only the debounce module and its internal dependencies import debounce from 'lodash/debounce'; // ES-module distribution: elimination is possible import { debounce as debounceEs } from 'lodash-es'; ``` 1. **Deep import the submodule.** Works today, needs no dependency change, and is enforceable with a lint rule that bans the root import. 2. **Switch the distribution.** Moving to `lodash-es` fixes it at the source, but check that no transitive dependency still pulls the CommonJS copy — otherwise you ship both. 3. **Replace or inline.** One helper rarely justifies a dependency. A debounce, a `groupBy`, a deep clone are each small enough to own, and several now have platform equivalents. 4. **Accept it deliberately.** If the library really is load-bearing, record that the bytes are a known, argued-for cost rather than an accident. ## Why syntax alone is not the answer Candidates often reach for "use named imports" as the whole fix. Named imports are a precondition on *your* side, and they matter — but they do nothing if the module on the other side of the import cannot be split apart. Likewise minification is not elimination: a minifier renames identifiers and squeezes syntax in the code that is kept, while deciding a module is unreachable happens earlier, over the module graph. ## What a good answer sounds like Measure, attribute, name the module format as the likely cause, give a concrete remedy with a concrete import path, and then re-measure. The last step is the one weak answers skip, and it is the only part that proves the bytes actually went away.