Barrel files — those index.ts files that re-export everything from a folder — feel like a convenience. One import instead of five, paths that read cleanly, no hunting through the filesystem. But what looks like organization often becomes a bundling problem in disguise.

The issue is that bundlers have to parse the entire barrel to determine what's actually used. Even with tree-shaking, circular dependencies can form silently, and in large codebases, import chains grow deep. The result: slower cold starts, larger initial bundles, and module evaluation happening earlier than needed. I've seen build times spike noticeably after a team standardized on barrels without thinking about the consequences.

A concrete example: working on a mid-size dashboard with several feature-heavy modules, I opened Chrome's Network tab during a cold page load and counted over 1,600 module requests. Not all of them were barrel-caused, but after auditing the import chains and switching to direct imports across the feature folders — keeping barrels only at the design system boundary — requests settled between 900 and 1,100 depending on the route. Vite's build time dropped too, a few seconds shaved off a CI step that was already too slow. The change was unglamorous. Nobody noticed. That's how good infrastructure work tends to feel.

The practical advice is simple: favor direct imports for anything performance-sensitive, and reserve barrels for genuine public APIs — the surface of a library or a shared design system, not every subfolder of a feature. A small discipline that pays off quietly over time.

The hidden cost of barrel files