Minimizing library bundle-size impact on consumers

WHAT THIS TESTS This probes whether you treat bundle size as a measured, governed property of the library across all consumers, not a one-time tree-shaking checkbox.

A GOOD ANSWER COVERS Measurement first. Add a size budget tool like size-limit or bundlewatch to CI so any PR that grows a component's gzipped size beyond a threshold fails, making regressions visible at review time. Use a bundle analyzer to see what dominates and catch accidental heavy dependencies. Then minimize. Provide granular entry points so a consumer importing one component pulls only that component, and avoid barrel index files that defeat tree-shaking when consumers or their tooling cannot shake them. Externalize peer and shared dependencies so they are not duplicated. Code-split or lazy-load genuinely heavy components such as rich text editors, charts, or date pickers behind dynamic import so they cost nothing until used. Ship ESM with an accurate sideEffects field. Watch transitive dependency weight and prefer lighter alternatives. Publish per-component size in docs so consumers make informed choices.

COMMON WRONG ANSWERS Saying tree-shaking handles it and stopping there, with no budget or measurement. Shipping one barrel import that drags in everything. Bundling peer deps. Ignoring heavy transitive dependencies. Optimizing once and never guarding against regressions in CI.

LIKELY FOLLOW-UPS How do you prevent a barrel file from breaking tree-shaking. How do you decide what to code-split. How do you stop size regressions over time.

ONE CONCRETE EXAMPLE A consumer flags that importing your DatePicker adds a large date library. You code-split it behind a dynamic import, expose a granular import path, add a size-limit budget so future growth fails CI, and publish its gzipped cost in docs, so teams pay for it only when they use it and regressions are caught automatically.