First Load JS

[Mr-Meshky]

Hi,

I’m running into a bundle size issue in my Next.js 15 app.

Here’s my setup:

For each page (example /app/page.tsx), I import the page component from /components/pages:

// /app/page.tsx
import { Landing } from "@/components/pages";

export default function LandingPage() {
  return <Landing />;
}

And inside /components/pages/index.ts I export all pages:

export * from "./artist-detail";
export * from "./auth";
export * from "./landing";
export * from "./list";
export * from "./list-detail";
export * from "./onboarding";
export * from "./player";
export * from "./q";
export * from "./search";
export * from "./see-all-artist";
export * from "./select-artist";
export * from "./songs";

---

The Problem

When I do this, the build output looks like this (bundle sizes get really large, most routes around 432 kB):

Route (app)                                 Size  First Load JS    
├ ○ /auth                                  310 B         432 kB
├ ○ /home                                  327 B         432 kB
├ ○ /player                                327 B         432 kB
...
+ First Load JS shared by all             102 kB

But if I don’t use /components/pages/index.ts and instead import each component directly (e.g. import { Landing } from "@/components/pages/landing"), then the bundle sizes are much smaller and optimized:

Route (app)                                 Size  First Load JS    
├ ○ /auth                                1.07 kB         395 kB
├ ○ /home                                1.75 kB         375 kB
├ ○ /player                              2.26 kB         347 kB
...
+ First Load JS shared by all             102 kB

---

My Question

• Why does exporting everything in /components/pages/index.ts cause all routes to blow up in size?
• Isn’t tree-shaking supposed to remove unused exports?
• Is there a recommended structure or best practice for organizing shared page components without forcing them all into the shared bundle?

Thanks!

Additional information

"next": "15.5.0"
"react": "19.1.1"

Example

No response

[icyJoseph]

Quick follow up, are you using Webpack/Turbopack?

[Mr-Meshky]

Webpack

[Mr-Meshky]

It behaves correctly up to a certain point in the project, but from a certain point on, I feel like it has problems due to client and server rendering.

[icyJoseph]

Right, so the question we need to answer is, why do barrel-files not make tree shaking just work?

Barrel files tend to be problematic because bundlers often can't prove that dropping some code is ok, because it was side-effect free. Mostly we see this problem with icon libraries, or libraries that pack a lot of utilities, for that Next.js has. way to rewrite the imports for you, https://nextjs.org/docs/app/api-reference/config/next-config-js/optimizePackageImports, but it might be negatively be impact by side-effects.

Here's a thread that discusses barrel files: webpack/webpack#16863 (comment)

If you search around, you'll find many that say barrel files are anti-pattern.

I think there's a way to get this to work but it is, IMHO, brittle. I rather use proper imports and not barrel files. Telling bundlers that things are sideEffect free, but maybe you can infer it from here, https://webpack.js.org/guides/tree-shaking/#mark-the-file-as-side-effect-free

One other thing is that as that link says, in 100% ESM work it should just work - if I add "type": "module" - then it does drop it, with Webpack builds - I tested Turbopack and it didn't just yet. Nope I must have done something else... sorry about the misinformation.

Given all of this, one might as well just avoid the barrel-files - unless there's strong reason for it?

[Mr-Meshky]

Thank you for the explanation. Can you check if this structure is good or not? And give your suggestion about it?
https://g.co/gemini/share/2b43b93873d6

[icyJoseph]

These all look good on paper. While most projects I've worked at do a variation of a structure like that, I'd say the important thing across projects has been to stay consistent, and be able to adapt.

I should also add that today with /route/page.tsx kind of formats co-locating files with the route, and use them only within the, makes it easy to tidy up if the route is no eventually no longer needed. With route groups you can also scope entire projects to their own area and let them have their own components, etc.

[Mr-Meshky]

One of the answers I got on reddit:
AFAIK tree-shaking does not work with barrel files. At least it didn't 2 years ago, when we looked into it. If you hate dealing with import paths, use import aliases and enforce them with something like @limegrass/eslint-plugin-import-alias.