Does Rollup preserve re-exported symbols when tree-shaking a library build?

Short answer

It depends on which build you mean, and Rollup treats the two cases differently:

• Library build (your case): every export of the entry module is assumed to be reachable by external consumers, so re-exported symbols that form your public API are preserved, even if nothing inside the bundle uses them.
• Application build: only bindings actually imported through the entry survive. An unused export { x } from './mod' is dropped, and if that was the only reason mod was included, the module itself can be omitted too.

So the premise of the worry — that Rollup silently drops unused re-exports from a library entry — is generally unfounded. The public API declared by your entry is treated as live code.

Why re-exports behave this way

A re-export creates a binding, not a copy. Rollup traces that binding back to the defining module and keeps the underlying implementation alive as long as the binding is reachable. In a library build, reachability starts at the entry's export list, so the whole chain entry → barrel → implementation survives. This is also why barrel files (index.js that only re-exports) are safe with Rollup: downstream consumers using ES modules can still shake out the parts of your API they never import, because the ESM output keeps each symbol as an independent named export.

Output format and downstream tree-shaking

For maximum downstream tree-shaking, ship output.format: 'es' (or dual-publish with es as the primary module entry). ES output preserves static named exports, which is exactly what consumer bundlers need. CommonJS output wraps exports in interop helpers and a single exports object, which most bundlers cannot statically analyze — downstream tree-shaking degrades substantially. If you must ship CJS, treat it as a compatibility artifact, not the tree-shakable one.

Set sideEffects: false in your package.json (or scope it to files that truly have side effects, e.g. CSS imports or polyfills). Without it, consumer bundlers must assume every module has top-level side effects and will retain modules even when their exports go unused. Inside your own build, the equivalent control is treeshake.moduleSideEffects (default true, meaning "assume modules have side effects").

Where manual chunking can hurt

output.manualChunks overrides Rollup's natural splitting. Two practical risks for a library:

• Forcing unrelated modules into one chunk means importing one symbol pulls the whole chunk into a downstream graph, weakening the granularity tree-shaking relies on.
• Aggressive chunking can introduce extra facade chunks and re-export indirection; exports remain visible, but the output becomes harder for consumers to shake and harder for you to reason about.

For most libraries, prefer preserveModules: true (ES output) over manual chunking: it mirrors your source file structure, keeps each export independently reachable, and gives downstream bundlers the cleanest graph.

Verifying your setup

1. Create an entry that re-exports two symbols from separate modules. Build with format: 'es' and confirm both symbols appear as named exports — they are public API and must survive.
2. Write a small consumer app that imports only one symbol, bundle it with Rollup, and grep the output for the unused symbol's implementation. It should be gone.
3. Repeat with sideEffects: false toggled and compare bundle sizes to confirm module dropping works as expected.

// rollup.config.js (library)
export default {
  input: 'src/index.js',
  output: {
    dir: 'dist',
    format: 'es',
    preserveModules: true
  },
  treeshake: { moduleSideEffects: false }
};

Caveats

Side-effect detection is heuristic: modules with top-level side effects (logging, global registration) may be retained even when their exports are unused, which is usually correct. Exact behavior can vary across Rollup versions and with plugins such as @rollup/plugin-commonjs, whose interop can obscure re-export chains — verify against your installed version with the steps above rather than relying on defaults alone.