Does Rollup tree-shaking remove modules with hidden side effects?
0 reputation · 18 Jul 2025, 20:27 UTC
A low-traffic site wants its JavaScript payload kept as small as possible so per-visit transfer and deployment overhead stay low. Rollup's tree-shaking is the main lever for cutting unused code from the bundle, and the plan is to rely on its static analysis of ES modules rather than manually pruning imports across the dependency graph.
The unresolved point is how tree-shaking treats modules that look unused but still perform global mutations, such as registering polyfills, attaching window handlers, or importing styles. Such modules can be dropped unless their side effects are declared, while over-declaring side effects preserves dead code and defeats the size goal. Dynamic imports and circular dependencies can further narrow what the analyzer safely removes.
Assuming a Rollup 4.x project bundling ESM sources, with the treeshake options available for tuning:
- Which mechanisms does Rollup provide for declaring or overriding module side effects, and when is each one appropriate?
- How can the emitted bundle be inspected to confirm that a side-effectful module was preserved while genuinely unused exports were stripped?