DEV Community

Cover image for Barrel files and why you should STOP using them now

Barrel files and why you should STOP using them now

Tássio on August 12, 2023

Small decisions can also have big impacts on applications. When developers start using barrel files they might seem like a harmless pattern, but th...
Collapse
 
hernanarica profile image
Hernán Arica • Edited

Hace unos meses cuando descubrí este patrón, me pareció genial la forma en la que da una mejora claridad al leer los imports, pero usando react router 6 y un sistema de autenticación, me di cuenta de estos problemas que nombras, ya que la app no funcionaba como yo esperaba, debito a esto.

Collapse
 
tassiofront profile image
Tássio

Gracias por compartir, Hernan! Feliz por clarar 🚀

Collapse
 
rberbel2 profile image
rodrigo nahuel

Acabo de llegar hasta aquí por esto mismo. Estoy refactorizando mi router y no podía entender que, a pesar de estar usando Lazy imports, habían muchos componentes siendo cargados de igual manera.

Collapse
 
zalithka profile image
Andre Greeff

wow... that's fascinating. in hindsight, it makes perfect sense, but I honestly never thought about this.

I just tested this with an Angular project, created a production build as I had it (using barrel files), then went through and removed them, adjusting my imports accordingly, and the production build I made afterwards is substantially smaller! like.. 752.86 kB before down to 186.11 kB afterwards! honestly did not expect that much of a difference.

my work laptop is horrifically underpowered, to the point that it doesn't even handle ESlint checking things in the background while I code.. it seems like Biome doesn't kill it as badly though, so I'm definitely going to tell it to throw things at me if I try use barrel files again!

thanks for sharing this.. :)

Collapse
 
zalithka profile image
Andre Greeff • Edited

quick follow up here: the e18e website "Resources" page conveniently provides a direct link to Biome's noBarrelFile lint rule.

Collapse
 
tassiofront profile image
Tássio

Woow!! What an extraordinary result, @zalithka!! 😮 We are also getting nice results where I have been working.

How about the unit tests, have you noticed any improvement?

Thanks for sharing your amazing results and Biome (I have heard about it before, I will explore)!

Collapse
 
kasper573 profile image
kasper573

This is not necessarily true. You can have side effects free packages, which allow bundlers to properly tree shake packages that use barrel files: webpack.js.org/guides/tree-shaking...

Collapse
 
tassiofront profile image
Tássio

Hey, man! Thanks for your comment!

have you validated it? To be honest, I tried it a long time ago and it didn't work as expected. It might be my mistake... Anyway, I would not use Barrel Files due to its test impact. I don't believe Barrel files have so much value for this risk.

Collapse
 
kasper573 profile image
kasper573 • Edited

Yes, I use side effects free packages every day. Third party and my own packages. Three.js and ramda on npm are both side effects free to name a few popular ones.

For tests I definitely agree you shouldn’t be importing via barrel files. A unit test should depend on only its unit, regardless of tree shaking capabilities. I almost exclusively only use barrel files as a definition for what my packages export. Everything else I split up into separate modules so that my codebase can have a proper dependency tree.

I think your article demonstrates important concerns. If one wants a no-build architecture, then being aware of how modules work is very useful, and avoiding barrel files becomes more important. But if one has a build system already then you do have the option to tree shake. I don’t think it’s wise to pass judgement on a whole and say it’s either right or wrong. There are upsides and downsides, and everything depends on context of the team and project.

Thread Thread
 
tassiofront profile image
Tássio • Edited

Nice!! Thanks for the amazing explanation, man!

I will update my article to explain the context. Btw, do you know a nice article about no-build architecture? It is a new definition to me.

Another thing: if you want to create a topic regarding build system (on the barrel files context), I would love to put it in my article and give you the whole credit or if you have an article already, I can add the link here.

Please, find me on LinkedIn to talk if want to. Have a nice day!
linkedin.com/in/tassio-front-end/

Collapse
 
tomasz_jurek_dbd6cff8c585 profile image
Tomasz Jurek

The post’s title advocates for moving away from barrel files, but it's essential to recognize that their use can still be beneficial depending on the context. Barrel files can be particularly effective for single imports, allowing developers to streamline their code by simplifying import paths. Instead of referencing long or complex file paths for individual components, developers can use a barrel file to create a cleaner, more manageable import structure.

Additionally, when a project requires importing multiple related components at once, barrel files provide a practical solution. For instance, if you have several components grouped together, such as a set of page components that need to be included in a router, using a barrel file can facilitate a more organized import process. This approach not only reduces clutter in your import statements but also improves overall code readability.

Ultimately, barrel files remain a viable option for developers. When used for single imports or when needing to import a collection of related components, they can enhance the clarity and maintainability of the codebase. It's important for developers to assess their specific needs and determine when the use of barrel files can provide the most value.

Collapse
 
adi518 profile image
Adi Sahar • Edited

Sounds like it's in the context of a web app source and not libraries. In libraries, I think it's okay. Actually, how else would it be? you always have an entry file that exports everything.

Collapse
 
tassiofront profile image
Tássio • Edited

Exactly, @adi518, the focus here is final projects as said in the BEFORE YOU KEEP READING section. Although I also got diff numbers on Pako lib example, so I prefer avoid to import from entry points files when possible (but again, final projects).