Tree shaking internals

Slap yourself if

You think tree shaking is a minifier feature or believe unused exports are always removed automatically.

Why this exists

Because many teams ship bloated bundles while confidently claiming their code is tree-shaken — without understanding the semantic constraints that make removal illegal.

Mental model

Tree shaking is not code removal. It is static reachability analysis constrained by JavaScript semantics and side-effect guarantees.

  • The bundler builds a module graph using static import/export syntax.
  • Exports are marked as used or unused based on static reachability.
  • Modules or bindings with possible side effects are conservatively retained.
  • Final removal happens only after analysis, often during code generation.
  • Using CommonJS and expecting equivalent shaking.
  • Accidentally introducing side effects at module top-level.
  • Relying on dynamic imports or re-exports that defeat static analysis.
  • Assuming smaller bundles after switching tools without verifying output.

Tree shaking is static analysis over ES module graphs to remove unreachable exports, limited by side effects and dynamic behavior.

  • Calls it a runtime optimization.
  • Attributes it to minification alone.
  • Cannot explain why CommonJS breaks it.
  • Assumes unused code is always safe to delete.

Deep dive

Requires Pro

Premium deep dives include more internals, more scars.

Why tree shaking lives and dies on static structure

How harmless-looking code disables shaking

Why bundlers prefer bloat over breakage

How to verify tree shaking actually happened

Where experienced engineers still slip