Bundling a component library for tree-shaking
Optimizing a library so consumers ship less code.
ship ES modules, mark sideEffects false, preserve named exports, and externalize peers so consumers tree-shake and code-split.
What's really being asked
This probes whether you understand how a library author enables the consumer bundler to eliminate unused code and split it, because a poorly packaged library forces apps to ship the entire system even if they import one button.
The full answer
Tree-shaking is dead-code elimination based on static analysis of ES module import and export statements. To enable it, the library must ship an ES module build, not only CommonJS, because CommonJS dynamic requires cannot be statically analyzed. Mark the package with sideEffects false in package.json, or list the few files that do have side effects such as global CSS imports, so the bundler may safely drop unused modules. Preserve named exports per component and avoid forcing everything through a single barrel file that imports the whole library, since that can defeat shaking. Externalize peer dependencies like React rather than bundling them. Code-splitting is the consumer-side complement: large or rarely used components can be lazily imported so they land in separate chunks loaded on demand. The library should not pre-bundle in a way that blocks this.
The mistakes people make
Shipping only a minified CommonJS bundle prevents tree-shaking entirely. Setting sideEffects false when CSS side-effect imports exist can strip needed styles. Bundling React into the library bloats output and risks duplicate copies. Assuming minification equals tree-shaking conflates two different steps.
What usually comes next
Why does CommonJS resist tree-shaking? What breaks if sideEffects is misconfigured with CSS? How do the exports map and module fields direct bundlers? When does a barrel file hurt? How do you measure what actually ships, for example with a bundle analyzer?
A concrete example
An app imports only DatePicker from acme-ui. Because the library ships ESM with sideEffects false and per-component exports, the consumer bundler drops the other fifty components, and a heavy RichTextEditor is additionally code-split behind a dynamic import so it only loads on the editor route, keeping the initial bundle small.
Interview question
Why does shipping a component library only as a single CommonJS bundle prevent consumers from tree-shaking unused components?
- a.CommonJS uses dynamic requires that bundlers cannot statically analyzeCorrect
- b.CommonJS does not support named exports at all
- c.Tree-shaking only works on TypeScript source files
- d.CommonJS bundles are always larger than ESM bundles
Why? this is the answer
Tree-shaking relies on static analysis of ES module imports and exports; CommonJS require calls are dynamic and resist that analysis, so the whole bundle is kept. Shipping ESM with sideEffects false enables dead-code elimination.
Just read this? Test yourself on what you have been reading.
Read the original → webpack.js.org
- #bundling
- #tree-shaking
- #code-splitting
- #esm
- #performance
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles