What is the best way to use barrel files and get appropriate tree-shaking/code-splitting? Nx, Next, Monorepo

[telestrial]

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

export * from './lib/foo'
export * from './lib//bar'

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

export * from 'baz'

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

{
    "paths": {
        "@company/ui": ["libs/ui/src/index.ts"],
    }
}

which allows us to do this:

import { baz } from '@company/ui'

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.

[alexander-akait]

Do you have sideEffects in your package.json - https://webpack.js.org/guides/tree-shaking/#mark-the-file-as-side-effect-free?

[victorcarvalhosp]

I don't have this on my package.json. And I'm facing the same issue. Should I add it?

[victorcarvalhosp]

Just an update: I added "sideEffects": false, to my package.json and it decreased the bundle size at least by half - and everything is still working just fine.

[sibelius]

you can implement a loader to optimize https://vercel.com/blog/how-we-optimized-package-imports-in-next-js

[nfiacco]

Did you ever find a solution here?

[victorcarvalhosp]

Curious to know too. I'm facing the exact same problem.

[sibelius]

you need sideEffects: false to enable tree shaking

[edumats]

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 "sideEffects": false. to your package.json file.

[fsgreco]

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 index.ts file inside the libraries... it defeats the purpose and the convenience to have a monorepo...

[morganney]

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.