Small decisions can also have big impacts on applications. When developers start using barrel files they might seem like a harmless pattern, but th...
For further actions, you may consider blocking this person and/or reporting abuse
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 kBbefore down to186.11 kBafterwards! 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.. :)
quick follow up here: the e18e website "Resources" page conveniently provides a direct link to Biome's
noBarrelFilelint rule.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)!
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.
Gracias por compartir, Hernan! Feliz por clarar 🚀
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.
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...
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.
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.
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/
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.
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.
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).