What is the best way to use barrel files and get appropriate tree-shaking/code-splitting? Nx, Next, Monorepo #16863
Replies: 7 comments 3 replies
-
Do you have |
Beta Was this translation helpful? Give feedback.
-
you can implement a loader to optimize https://vercel.com/blog/how-we-optimized-package-imports-in-next-js |
Beta Was this translation helpful? Give feedback.
-
Did you ever find a solution here? |
Beta Was this translation helpful? Give feedback.
-
you need sideEffects: false to enable tree shaking |
Beta Was this translation helpful? Give feedback.
-
I had the same problem too, I had a barrel file from one of my dependencies which was importing dozens of modules that weren't being used. Webpack is supposed to remove modules that were not being used by imports in your app, but it does not remove them unless you add |
Beta Was this translation helpful? Give feedback.
-
I have the same problem but using Nx and vite (v5.0.12) and let me tell you is really annoying, the only way I have to reduce the bundle is by eliminating the components fromt the main |
Beta Was this translation helpful? Give feedback.
-
Barrel files are such an anti-pattern. The convenience is not worth the headache. Try to avoid them and instead be explicit about where your imports are coming from. Doing so also helps you to avoid cycles in your architecture. |
Beta Was this translation helpful? Give feedback.
-
Greetings.
I am currently trying to track down an issue around tree-shaking/code-splitting and have come to the conclusion that it must have something to do with how webpack handles modules. I apologize for how scattered this description may seem, but I supply a repo demonstrating what I'm talking about down below, with instructions about how to replicate.
We use the nx build system and have a next app and then libraries for constants, business logic, ui, etcetera. So our top level folders of concern are apps/ and libs/. Inside the app folder, we implement a pretty straight-ahead next app, bringing in code from our libraries through their top-level barrel files, with aliasing using paths in the tsconfig.base.json
In our libs folder, we have different nx-generated react and javascript libraries. When these generate, they have index.ts barrel files, and we use them. So a barrel file might be
libs/ui/src/index.ts
Foo and bar would be subfolders within this library, with their own barrel file, exporting different things out of their local folder. Like so:
libs/ui/src/libs/foo/index.ts
where baz is a non-default exported react component, for example.
Finally, we set tsconfig.base paths around the top-level barrel file, like this:
tsconfig.base.json
which allows us to do this:
It works insofar as we get autocomplete/intellisense in vscode, but it may have an unintended consequence when its comes to building the next app. It appears that when you import anything from '@company/ui', like a baz, everything from that top-level library barrel file is included in the chunk--even code that never runs.
Does webpack interpret barrel files as "import all of this no matter if it's used or not" ?
This behavior may very well be intended. That's why I'm posting it in a discussion and not an issue, but I would like to better understand how webpack handles this situation.
If all that was confusing, no worries, here's a repo: https://github.com/telestrial/nx-webpack-barrel-issue
Just follow the README instructions to understand what I mean. The assumptions I'm making are there.
Thank you!
EDIT: One final detail regarding my linked repo: This is not just a development problem. I have confirmed that what you see in coverage is what gets included in a production build/bundle/chunks.
Beta Was this translation helpful? Give feedback.
All reactions