Hi!
This is a short post about how to create a useful import/export strategy on Typescript. Now, this is not an exclusive Typescript feature, but ...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
You should also add - don't do that ;)
Sorta. Don't do that... with a blanket export.
Having an index barrel with all available exports can be very useful for readability and makes it easier to move/rename the implementation files. (Think
__init__.pyindexes in python.) It also allows for implicit private exports which can be more easily respected by a module consumer.That said,
export * from 'foo'introduces magic that may in fact produce more opaque code instead. Prefer explicitly exporting the relevant symbols as an actual index.I do believe the barrel pattern is useful in some cases. Like say, an API interface, so you can call the APIs with something like
api.user.get, so user gets autocomplete on the APIs can narrow down from there. But putting interfaces/components there in the same name can get confusing real quick. With editors like VS Code that support automatic imports, all users would see two imports for this and then might end up picking the wrong one making the barrels kinda useless.Hi! What did you mean?
Tell me why I should maintain one + file for every directory and what is an issue to import file directly? And who puts one interface per file?
Probably more prevalent in declarative styles of codebase? I would see one or more varients in one file. But not just one interface.
Webpack has issues tree shaking this.
I've unfortunately learned the hard way at this. I love barreling and it does clean up your code considerably... But it harms all of the bundlers ability to tree shake (even when you have all the output for ES2017 or newer).
I'm currently undergoing a massive refactor in which I'm stripping all the barrels.
what did you do instead. I'm planning to do the same removing the barrel. but i couldn't find the right way.
My file importing so many components that I ended up have more than 50 lines only importing components
To be honest, me neither. What I ended up doing was only barreling those files that I know they were going to be used together, and manually removing each of the other ones... Yes, I spent many many hours in the refactor... But it was worth it.
Plus I used type aliases (works both on Babel and TypeScript) to better index my applications.
Hi, thanks for the post. I just want to add that this can have a direct impact in bundle size. This is the case with webpack (for example) if you dont have tree-shaking properly configured. It is recomendable to import the file you need directly as others pointed out already.
I'd advise against barrels.
Unless your code is marked as
"sideEffects": false, using the barrel module will import all of the import tree.This is fine for small isolated groups of modules, but in a larger codebase, a single import can instantly broaden the "import tree". This slows down builds, mostly.
So, for large and complex codebases, don't even think about using barrels (unless of course you have
sideEffects: falseenabled).Great article! Barrels are cool and all until you get an import order issue in a big application and then they're not so cool.
Could you give an example of what that looks like?