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

[scameron]

That is a really good idea. Do you know where the code for the optimizePackageImports implementation is kept? I couldn't find it in the Next.js repo.

[younggglcy]

That is a really good idea. Do you know where the code for the optimizePackageImports implementation is kept? I couldn't find it in the Next.js repo.

Next.js's solution is somehow heavy.

• on Rust side integrated with swc, named_import_transform.rs transform the imports to a barrel-file-lib into '__barrel_optimize__?names={}!=!{}' format to keep track of which named imports are used, optimize_barrel.rs process the barrel file and exports some meta informations
  • __next_private_export_map__ describes the exports information of a barrel file
  • wildcard export is processed in __barrel_optimize__?names=__PLACEHOLDER__!=!{src} format
  • __next_private_directive_list__ describes directives(use client, use server)
• on Webpack/Rspack side, next-barrel-loader calls transform(provided by Rust implementation) on the file, and does optimizations for the barrel file based on information Rust side provided.

e.g., One importer file A has an import { foo, bar } from 'baz' and 'baz' is a package using a barrel file as an entry file

1. swc transform it to import { foo, bar } from '__barrel_optimize__?names=foo,bar!=!baz'
2. a request with __barrel_optimize__ hits next-barrel-loader loader
3. Loader parses the export map, resolves only the needed exports
4. For file A, loader returns the contents like export { foo } from './foo'; export { bar } from './bar'
5. Thus, webpack bundles only node_modules/baz/dist/foo.js and node_modules/baz/dist/bar.js

Notice: This only represents my personal opinion and may not be correct.

[nfiacco]

Did you ever find a solution here?

[victorcarvalhosp]

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

[oliverstreissi]

@nfiacco @victorcarvalhosp currently working in a nx repo, with that exact issue. Did you find a solution that properly solved that?

[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.

[jmroon]

How would you propose writing a modular architecture without barrel files? Typically, each module has a public api defined in a barrel file. This can be enforced through linters.

[morganney]

I guess I don't understand what problem you are trying to solve?

What could be more modular about an architecture than actually using named exports, imports using the module specifier, import maps if you want to define specifiers differently, or renaming imports and exports if you need to avoid name collisions of some kind?

Typically, each module has a public api defined in a barrel file.

From my personal experience I'm advocating against that. I recognize barrel files as an anti-pattern for most projects. Most of the time they will:

• Increase the size of your build
• Cause cyclic imports

Both of which you want to avoid.

If you want to expose a public API from a module, then use named exports (you can have as many as you like in a module) and only export { somePublicFunctionality } which can reference other identifiers and benefit from the closure over module scope.

How would you propose writing a modular architecture without barrel files?

In short, use ES module features.

[anilanar]

They cause cyclic imports when the modules are not obeying the "rules of modules" and they are not structured in a way to obey hierarchy of dependencies. That's just a sign that you have bad modules, not that barrels are bad. Instead barrels help you root them out.

Yes, existing tooling isn't very friendly to barrels. That's a disadvantage, but I wouldn't call barrels an anti pattern, which is something library/tooling authors keep parroting about because they get tired of people complaining about bundle sizes, slow bundling/compilation and such.

[anilanar]

If you want to expose a public API from a module, then use named exports (you can have as many as you like in a module) and only export { somePublicFunctionality } which can reference other identifiers and benefit from the closure over module scope.

That's already something barrel users do. What they mean by a public api is they split their larger module into smaller modules, most of which are internal and shouldn't be available to the outside. That intent is made clear with barrel files.

That's basically the same idea with npm packages (and package managers for most other langs follow the same pattern!). An npm package that does one thing typically reexport everything that should be public in their main exports and deep importing has long been considered an anti-pattern, until "oh no barrels make tooling inefficient what do we do now, let's declare it an anti-pattern".