What Is Dead Code Elimination and How Does It Work?
Learn how dead code elimination and tree-shaking work with ES modules, sideEffects flags, and common blockers.
Expected Interview Answer
Dead code elimination is a build-time optimization where the bundler statically analyzes which exported code paths are never imported or used and removes them from the final output, most commonly implemented via tree-shaking based on ES module static import/export analysis.
Because ES modules have a static structure — imports and exports are declared at the top level and cannot be conditionally renamed or computed at runtime — bundlers like Webpack, Rollup, and esbuild can build a precise dependency graph and prove that a given export is genuinely unreachable from any entry point, then safely delete it (unlike CommonJS’s require(), whose dynamic nature makes this analysis far harder). This differs from minification’s dead-code removal, which mostly strips code following unreachable branches like `if (false) { ... }` within a single function; tree-shaking works at the module-export level across the entire dependency graph. For tree-shaking to work, a package must be written with side-effect-free ES module exports and typically declare `sideEffects: false` in its package.json so the bundler knows it’s safe to drop unused exports even if importing the module could theoretically run top-level code. Common blockers include re-export barrel files that import everything just to re-export it, code with actual side effects at module scope (like a CSS import or a global polyfill registration) that forces a bundler to keep the whole module for safety, and CommonJS-only packages that cannot be statically analyzed at all.
- Removes exported code that is never actually imported anywhere, shrinking bundle size
- Works at the whole dependency-graph level, catching more than local minifier dead-branch removal
- Encourages side-effect-free, ESM-first package authoring that benefits the whole ecosystem
- Combined with code-splitting, ships only the functionality a given route actually needs
AI Mentor Explanation
Dead code elimination is like a kit manager reviewing the full equipment catalogue and removing every item no player on the squad has ever actually requested for a match. Because the equipment list is tracked with clear, fixed labels rather than vague notes, the manager can prove with certainty that a spare set of gloves was never used by anyone. Items only get kept if there’s real evidence someone could still need them, like gear referenced in a training plan even if unused this season. That prove-it’s-truly-unreachable-then-remove discipline is exactly how tree-shaking eliminates dead code.
Step-by-Step Explanation
Step 1
Build a static module graph
The bundler analyzes ES import/export statements across all modules, since ESM structure is statically knowable at build time.
Step 2
Mark reachable exports from entry points
Starting from the entry file(s), the bundler traces which exports are actually imported and used anywhere in the graph.
Step 3
Check for side-effect safety
It checks package.json “sideEffects” and per-module top-level code to decide whether an unused export is safe to drop.
Step 4
Strip unreachable exports and dead branches
Unused exports are removed from the graph, and the minifier further strips unreachable code paths within remaining functions.
What Interviewer Expects
- Understanding that tree-shaking relies on ES module static structure, unlike dynamic CommonJS require()
- Ability to distinguish tree-shaking (module-graph level) from minifier dead-branch removal (function level)
- Knowledge of package.json “sideEffects”: false and why it matters for library authors
- Awareness of common blockers: barrel files, module-level side effects, CommonJS-only packages
Common Mistakes
- Assuming any unused code automatically gets removed regardless of module format
- Not knowing why CommonJS require() defeats most tree-shaking analysis
- Ignoring how barrel/re-export index files can prevent effective tree-shaking
- Forgetting to mark a side-effect-free package with “sideEffects”: false in package.json
Best Answer (HR Friendly)
“Dead code elimination, usually called tree-shaking, is when the build tool looks at your whole codebase, figures out which pieces of code are never actually used anywhere, and cuts them out of the final file that ships to users. It relies on modern import/export syntax being predictable enough for the tool to prove a piece of code is truly unused before removing it.”
Code Example
// math.js — individual named exports, fully tree-shakeable
export function add(a, b) { return a + b }
export function multiply(a, b) { return a * b }
export function unusedHelper() { return 'never imported anywhere' }
// app.js — only imports what it needs
import { add } from './math.js'
console.log(add(2, 3)) // multiply and unusedHelper are dropped from the bundle
// package.json for a library, so bundlers know it’s safe to prune
// { "name": "my-lib", "sideEffects": false }Follow-up Questions
- Why does CommonJS require() make tree-shaking significantly harder than ES modules?
- What does the “sideEffects”: false field in package.json actually tell the bundler?
- How can a barrel/re-export index file accidentally defeat tree-shaking?
- How does tree-shaking differ from the dead-branch elimination a minifier performs?
MCQ Practice
1. What structural property of ES modules makes tree-shaking possible?
Static import/export declarations let bundlers build a precise, analyzable dependency graph.
2. What does “sideEffects”: false in package.json tell a bundler?
It signals that importing the module without using any of its exports is safe to eliminate entirely.
3. Why can a barrel/re-export index file hurt tree-shaking?
Depending on the bundler and module content, barrel files can obscure which specific exports are truly used.
Flash Cards
What is dead code elimination in bundlers usually called? — Tree-shaking — removing unused ES module exports from the final bundle.
Why does CommonJS resist tree-shaking? — require() is dynamic, so bundlers cannot statically prove what is unused.
What package.json field aids tree-shaking? — "sideEffects": false, telling the bundler unused exports are safe to drop.
Tree-shaking vs minifier dead-branch removal? — Tree-shaking works across the whole module graph; minifiers strip unreachable branches within a function.