Barrel files — those innocent index.ts re-export hubs — are one of the most popular patterns in the React ecosystem, and one of the most expensive. In dev mode there is no tree-shaking: a single `import { Button } from '@/components'` drags every re-exported module into the compile graph. I measured just how much that costs. In a synthetic Next.js lab, shrinking a 2000-module barrel down to 200 re-exports cut dev-server memory growth by roughly 88%. In a real production codebase, de-barreling the shared module graph took a blank page from 6,780 compiled modules and ~4.9 GB of dev memory down to 2,215 modules and ~2.3 GB — while config-only "fixes" like optimizePackageImports quietly failed to move the needle. In this talk I'll walk through the experiments and the numbers, show which import styles actually determine what enters the module graph, and close with concrete guidance for library authors: how to design entry points and exports maps so your users never have to pay the barrel tax.
