❌ Don't use barrel imports in React ✅ Import components directly Barrel imports (index.js re-exports) import the entire module even if you need one component. This adds unused code to your bundle ↓

Barrel exports do not add unused code! Modern bundlers track the deps and eliminate them at the minification phase

assuming you use a modern bundler with tree-shaking enabled tho.

also if a consumer of your lib/package marks it as external, tree-shaking doesn't help. Importing a Button, will result in importing all unused code. As a best practice I avoid barrel files at all costs.

For libs you don’t need top level barrel files, specify “exports” in package json instead. In app it’s fine to use barrel exports

All the hysteria about barrel exports coming from vite, because it doesn’t tree-shake in dev mode, resulting in slower cold-starts. IIRC, rolldown should solve it though.

Not correct! Barrel files are a "problem" across the board. That's why companies like @vercel (specifically for @nextjs) wrote about it. Will it get better in Vite with Rolldown? Yes, mostly! There is potential for optimization that will be implemented (at this very moment actually), but there are still caveats depending on the use case.

@_georgemoller @vercel @nextjs They mentioned they solved the dev mode cold start issue. Also, I think I was a bit misleading in blaming Vite specifically. The barrel files issue exists in every bundler that compiles only requested modules (don’t bundle in dev mode).

@_georgemoller @vercel @nextjs Barrel files are not free, bundlers still need to tree shake them. But they are not bad as people say!

I've been working professionally with React for more than 8 years and I compiled all my knowledge into 100+ infographics and 70+ video tutorials just like this one. Check them out ↓

But isn't the tradeoff sometimes worth it for simpler imports and easier maintenance, especially in larger projects.

I don't think ergonomics is a fear tradeoff in this case, given that it can potentially bloat your (and consumers) bundle.

Yup. Explicit imports keep bundles lean and clean! Great video, short and to the point!

thanks! glad you liked it

I worked in a company that used a lot of barrel imports. They wondered why the app took 1 minute to hot reload. I searched in the Vitejs documentation and barrel import was the problem.

yeah as a best practice I just try to avoid them all together, negative impact surpass any ergonomic benefit that it might have.

I’ve seen barrels bite hardest in component libraries and design systems, less so in well-configured app builds.

that's true in component libraries they are usually a problem

Thanks for this video, I have some code like this, will refactor immediately

@techdevdaily glad you liked it!

And it's additional redundant code

next.js + turbopack handle this well in most cases

First time hearing of barrel imports💀

This is a good tip. Doing it myself without asking any questions. I feel smarter now.

@ShadowEmployee_ Glad you found it useful!

This is a good idea, and I adopted it when building my UI library for React Native: Bleeech. However, with tree shaking, you shouldn't have to worry about this.

@grok is this true for @nextjs 16?

This is only true if you use a shitty bundler. Import elision is a trivial problem in ESM, the devs are just lazy.

This post was for me. I just had an issue with circular dependency. We use barrel a lot in our nx project. Thanks

Love it came at the right time Michael! and yes circular dependency is another downside and potential issue of using barrel files.

Hopefully this decreases the bundle size and speeds the app start up time

Is this also the case in latest versions of vite?

Tree-shaking not present in 2026 is a crime.

Just use es linters to stop your devs from exporting multiple components from a single file. Kill your problems at the root.

So using: Import * as React from “react” is not correct? I need to import useEffect, useState independently?

Yeah we had a time where we faced this issues and solved by exporting the necessary things. Great win on bundle size 💯

You should use the reexport pattern if the whole component cannot exist without each subcomponent

Tree shaking? Vite? Am I missing something?

Why are you so bothered about the imports? Doesn't your IDE manage them automatically so you never look at them?

@grok is this true for expo project and what settings can be done to tree-shake

Barrel imports also tend to cause import cycles and especially in jest tests those import cycles make you cry from imports being undefined and the debugging being hell

Cool, so now I need to refactor all my imports in @bunvelhq 😅

I get how barrel imports can be bad in libraries, but what's the point of that in components from your OWN project? If you don't use a component anywhere else, you delete it, simply. In the end, your whole project WILL be imported at some point, so what? ~All generalism is bad~

@grok what software is he using to make the videos?

@grok, for which React frameworks is this true?

@grok is this true in nextjs?

tree-shaking usually fixes that with esm setups

surely this should be a problem that bundlers solve and developers shouldn't have to worry about?

KISS cause sometimes (always) we tend to forget