An app imports a single function from a barrel `index.js` whose body is nothing but `export * from './...'` lines covering forty modules, yet most of those modules still end up in the production bundle. What about that barrel undermines tree shaking, and how would you change it?

## What a barrel is and why teams write them A barrel is an index module that re-exports a directory's public surface so consumers write one import instead of many: ```js // components/index.js export * from './button.js'; export * from './modal.js'; export * from './date-picker.js'; // ... forty more ``` Consumers then write `import { Button } from './components/index.js'`. The ergonomics are real; the build-time consequences are what interviewers probe. ## Step one: the whole directory joins the graph When the bundler resolves the barrel, it must resolve every specifier the barrel names. It cannot skip `./date-picker.js` on the grounds that nobody wants a date picker, because with `export *` the *set of names* the barrel exports is exactly the union of what each of those modules exports — so it has to read them all to know where `Button` comes from and to detect ambiguities. Forty modules are parsed, plus everything they import. This parse cost is unconditional. Even in the happy case where thirty-nine modules are dropped, you paid to read them, which is why large barrels are a common cause of slow dev-server startup and slow rebuilds. ## Step two: each module is judged on its own side effects Once in the graph, each module gets the ordinary treatment: unused bindings are dropped, and the module's evaluation is skipped only if its top level is provably free of observable behaviour. So the outcome is not "barrels break tree shaking" but something sharper: - Forty modules of pure declarations: all but one are dropped. The barrel cost you build time and nothing else. - One of the forty registers itself, patches a prototype, or calls an opaque function at the top level: that one is retained, along with everything it needs, though your app referenced none of it. - One of the forty imports a dependency with import-time effects: the dependency comes along too. With forty modules the odds of hitting the second or third case approach certainty, which is why the barrel gets blamed. It is not the mechanism; it is the blast radius. ## Step three: re-export chains amplify Barrels compose. A package barrel re-exports feature barrels which re-export component barrels. One import from the top pulls the transitive closure of every barrel below into the graph. It is also how circular structure sneaks in: module A imports the barrel, the barrel re-exports module B, and B imports the barrel back, creating a cycle whose evaluation order is easy to get wrong. ## What actually fixes it **Import deep, not through the barrel.** `import { formatDate } from 'lib/format/date.js'` puts exactly one module in the graph. For internal code this is the single most effective change; the cost is longer import paths. **Prefer explicit re-exports over `export *`.** ```js // clearer, and the name-to-module mapping is stated rather than derived export { Button } from './button.js'; export { Modal } from './modal.js'; ``` This does not by itself let the bundler skip parsing (it still resolves each specifier), but it removes the ambiguity-resolution work, keeps the barrel's surface intentional, and makes an accidental new export visible in review rather than automatic. **Declare side effects honestly.** A package whose files really are pure can say so in `package.json`, which lets the bundler skip evaluation of unused modules without proving purity itself. That is what makes a well-published library's barrel tolerable while an unmarked application barrel is not. **Keep effects out of leaf modules.** The barrel is only as shakeable as its worst member. One `registerComponent(...)` at the top of one file is enough to keep that file permanently in every consumer's bundle. **Consider not having a barrel at the package boundary.** Many libraries now publish subpath entry points instead, so consumers reach individual modules by path rather than through one giant index. The ergonomic loss is small; the graph shrinks dramatically. ## How to confirm the diagnosis Do not reason about it from source — inspect the emitted bundle and look for module identifiers you never imported, then trace which import edge pulled each one in. The chain almost always ends at a barrel plus one impure leaf. Reasoning alone tends to blame the barrel wholesale, when the actionable finding is usually a specific module doing work at import time.