Tree shaking doesn't work with Typescript barrel files

[majelbstoat]

Bug report

I originally raised this as a discussion, but now I think it's a bug.

Describe the bug

When using a barrel file to re-export components from a single location, tree-shaking does not function correctly.

To Reproduce

I'm using Next 9.3.6 and I've arranged my components like:

  components/
    Header/
      Header.tsx
    Sidebar/
      Sidebar.tsx
    index.ts

Each component file exports a single component, like this:

export { Header }

index.ts is a barrel file that re-exports from each individual component file:

  export * from './Header/Header.tsx'
  export * from './Sidebar/Sidebar.tsx'
  // ...

I then use a couple of components in _app.tsx like:

import { Header, Sidebar } from "../components"

There's about 100 components defined, and only a couple are used in _app.tsx. But when I analyze the bundle I have a very large chunk, shared by all pages, and it contains all my components, resulting in an inflated app page size:

I use a similar import strategy within pages, and every one of them appears to contain every component.

my tsconfig.json is:

  "compilerOptions": {
    "allowJs": true,
    "baseUrl": ".",
    "forceConsistentCasingInFileNames": true,
    "esModuleInterop": true,
    "isolatedModules": true,
    "jsx": "preserve",
    "lib": ["dom", "dom.iterable", "esnext"],
    "module": "esnext",
    "moduleResolution": "node",
    "noEmit": true,
    "noFallthroughCasesInSwitch": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "preserveConstEnums": true,
    "removeComments": false,
    "resolveJsonModule": true,
    "skipLibCheck": true,
    "strict": true,
    "target": "es5"
  }

and I'm using next's native support for the baseUrl field. I haven't changed the module or the target.

When I change the _app.tsx imports to:

import { Header } from "../components/Header/Header"
import { Sidebar } from "../components/Sidebar/Sidebar"

the common bundle and app page size drops dramatically, as I would expect it to:

Expected behavior

The app page size should be the same using both import strategies.

System information

• OS: [e.g. macOS]
• Version of Typescript: [e.g. 3.8.3]
• Version of Next.js: [e.g. 9.3.6]

[timneutkens]

Feel free to investigate and solve

[rahul3103]

#13490

Same happening with jsx also.
version: 9.4.2

[seeekr]

Has anyone been able to solve this? In one of our projects we seem to be getting no tree shaking at all for any TS application code, only for third party library code.

Alternatively, could any of the maintainers provide some hints as to how one would best go about investigating and solving such an issue?

EDIT: For posterity, the problem in our case was that the bundle analyzer's output is harder to interpret correctly than it appears, which we failed to do initially. It seems that tree shaking was not the problem.

[stevethatcodes]

Has anyone been able to solve this? In one of our projects we seem to be getting no tree shaking at all for any TS application code, only for third party library code.

Alternatively, could any of the maintainers provide some hints as to how one would best go about investigating and solving such an issue?

@seeekr We actually ended up just removing our barrel files.

I did a simple experiment with Webpack and a couple of JavaScript modules + a barrel file (no Next, or Typescript) and the same behaviour was present with limited options to enable tree shaking to occur.

If you have no side effects in your code then you may be able to look into the Webpack side effects setting to allow this to work for you, but as soon as you're importing a module classed as a side effect, you may start to notice issues. For us, our polyfill imports stopped working along with a whole host of other stuff.

I'm not sure this is something Next can/should solve though, as it seems to be inherent to Webpack

[VWSCoronaDashboard8]

@stevethatcodes @majelbstoat Tree shaking seems to work for me as long as I specify side effects in package.json:

"sideEffects": [
    "./src/some-side-effectful-file.js"
  ]

This is according to the Webpack docs linked above. I think you would just have to determine where your polyfills and other side effects are happening and add those files to the side effects list.

[stevethatcodes]

@VWSCoronaDashboard8 Yeah, that's an approach we tried, though still had issues with the polyfills not loading. In fairness, we took the approach to remove barrel files as the path of least resistance, as they didn't add much value and we didn't need to do anything else to our Next/Webpack setup to bring back tree-shaking.

[RobbyUitbeijerse]

@sphilee I don't actually think it works / resolves the issue, I've installed Webpack 5 on my current Next.js projects but it doesn't have any positive impact on the bundle size, at least for barrel files structured as the issue example by @majelbstoat.

[VWSCoronaDashboard8]

@RobbyUitbeijerse @sphilee I have concluded the same. Webpack 5 didn't solve this issue for me.

[RobbyUitbeijerse]

Based on the following issue webpack/webpack#11821 , Webpack 5 should actually eliminate dead code with the minimize option being enabled (which is the case by default for next build). Let's assume that it does (I haven't actually verified it myself) -

What I'm concerned about is that it might actually work for the shared bundle which is loaded for all pages, but doesn't actually consider the page by page chunks, meaning that while dead code is actually eliminated from the shared bundle - you are still left with a single bundle containing everything instead for smaller chunks per page that only contain what you need for that page. Quite unsure whenever it's possible to actually resolve that or that changing the imports is the only way to go.

[RobbyUitbeijerse]

@timneutkens Webpack is not my strong suit, but do you have any clue if my comment above makes any sense in terms of what we are seeing?

[kelvinlouis]

I had similar issues in the past when using export * from 'xxx';. Have you tried explicitly re-exporting your named and default exports in the barrel files?

In the past we also had issues with babel when it came to exporting types. Since then we started exporting types explicitly using export type.

// index.ts
export {
  default as Header,
  HeaderX,
  HeaderY,
} from './Header/Header.tsx';

export type {
  Props as HeaderProps,
  AdditionalHeaderTypeX,
} from './Header/Header.tsx';

export {
  default as Sidebar,
  SidebarX,
  SidebarY,
} from './Sidebar/Sidebar.tsx';

export type {
  Props as SidebarProps,
  AdditionalSidebarTypeX,
} from './Sidebar/Sidebar.tsx';

[RobbyUitbeijerse]

I actually started doing the same recently:

But it turns out, no luck:

What I did find tho, that when I put all of the components in an external library and build that library using Rollup while preserving the modules, tree shaking of the same components seems to work properly, meaning that it should be possible to get it all working one way or the other.

[edit] Same result with webpack 5

[nandorojo]

I actually started doing the same recently:

Same experience here. I was pulling my hair out trying to figure this out. I have a monorepo, and in the index.ts of each package, I was re-exporting my components. Not only did this break tree shaking: it also made yarn next dev take like a minute longer to load. Changing my imports directly to the root file of the components solved this. Wish I'd known this sooner – I have a lot of imports to change.

I can make a repro in a monorepo this weekend.

I'm using Next 10.1.4-canary.2 and webpack 4, for context.

[JoeyFenny]

This has been open for over a year. Has anyone found a solution yet? Using a barrel file results in my bundle reaching 12mb whereas without I'm less than 1mb

[R-Bower]

@JoeyFenny
I managed to get this working by setting "sideEffects": false in the package.json of the package with the barrel export. You may also want to check this comment: #12557 (comment)

[jrmyio]

I am running into simular problems in a non next.js project. Upgrading from webpack 4 to webpack 5 did not fix it, sideEffects: "false" in the package.json does enable tree shaking but the barrel pattern still fails.

I think this is a webpack problem, maybe we should move the dicussion there?
Though it would really help if we got a minor example repository that shows the problem.

Important edit: It seems I was wrong that tree shaking wasn't fully working in my webpack project because of the barrel pattern. The barrel pattern (vs direct importing) made a lot more code be processed which increased the chance of tree shaking not being applied because of sideEffects within that code.

I don't know OP's exact case or next.js's handling when it comes to tree shaking vs webpack 5 but I did came accross a blog post that goes more in-depth on tree shaking that I would recommend reading: https://dev.to/livechat/tree-shaking-for-javascript-library-authors-4lb0

In the end I had to add /*#__PURE__*/ to some function calls to let tree shaking be applied correctly.

Again, I don't know if OP has the same issue, or there is some config issue or if it is next.js that is failing, but what I did found out is that webpack 5 does support the barrel pattern.

[JoeyFenny]

settings sideEffects to false and adding /*#__PURE__*/ to the function call did not work either. But I agree that this discussion should perhaps be moved to webpack

[b2rsp]

We dont have any news or ideas about this? I am really struggling to fix this since its having a big impact in our page load.

[sokra]

For tree-shaking to work with a barrel file you need

• flag the file and/or the child files as side effect free ("sideEffects": false in package.json)
• build in production mode webpack 4 or 5
• not bundle the library (it must be in separate files for sideEffects to work)
• Alternatively to side effect free flagging you can use /*#__PURE__*/ to carefully flag statements that might be considered as having side effects. If you do that, you must minimize to file to see the effect. This is very tricky to get right

[nandorojo]

not bundle the library (it must be in separate files for sideEffects to work

@sokra I want to have barrel files as the main file for each of my monorepo's packages. If I am adding these monorepo packages to next-transpile-modules, would that constitute "bundling" the library?

[JEGardner]

I have spent days trying basically everything I can think of to get Tree Shaking to work with the app router and barrel files, including all the suggested answers here, and have hit a dead end.

Half my pages use the Pages Router, and half use the App Router. The Pages Router pages seem to perform tree shaking on the barrel files properly, but the App Router pages are all double the kB of the Pages Router pages as soon as I import a single component.

Here's what I've tried so far:

• Moved all components into another package in my monorepo, and added sideEffects: false to that package.
• Many variations of editing the webpack config rules with sideEffects: false, both when the components were in the same package and in the new package. Interestingly, adding sideEffects: true doubles the size of the Pages Router pages, but the App Router pages stay the same.
• Many attempts with both Babel and SWC
• I think I am unable to use modularizeImports as I split my components into feature folders with a few layers of barrel files.

The only thing that works is bypassing the barrel files and importing components one by one... but I love barrel files and this seems like a (very time-consuming) step backwards. I think Babel Direct Import Plugin may have worked, but I couldn't get it to work.

I am pretty amazed that it doesn't just work out of the box as it seems like such a common thing to do and the whole point of NextJS is things are supposed to work out of the box.

[JEGardner]

An update on the above: I couldn't wait for a fix so I spent a day refactoring out my beloved barrel files so all my files now have tons of separate imports. My App Router routes dropped from ~640kB to ~80kB first load JS.

[dannyk08]

An update on the above: I couldn't wait for a fix so I spent a day refactoring out my beloved barrel files so all my files now have tons of separate imports. My App Router routes dropped from ~640kB to ~80kB first load JS.

@JEGardner would it be possible to point the rest of us mortals on how to optimize these bundles? I'm at a loss on how to optimize my @aws-amplify and @shopify/polaris imports

Thank you 🙏🏽

[enchorb]

+1 here, using a Nx monorepo and no tree-shaking is being done on the app router for custom libraries

[Rafi993]

An update on the above: I couldn't wait for a fix so I spent a day refactoring out my beloved barrel files so all my files now have tons of separate imports. My App Router routes dropped from ~640kB to ~80kB first load JS.

@JEGardner would it be possible to point the rest of us mortals on how to optimize these bundles? I'm at a loss on how to optimize my @aws-amplify and @shopify/polaris imports

Thank you 🙏🏽

+1

[cseas]

Is this issue now fixed with Optimized Package Imports? #54695

[ivan-kleshnin]

@cseas in my project this option did NOT affect the bundle size. I listed about 10 new libraries along with @headlessui and @heroicons that I'm using and that should be auto-included... – no effect. Might be because I already had sideEffects: false and other webpack gimmicks – I dunno.

And total bundle size with Next 13.5 actually increased by 2kb 🤦‍♂️

[william-fargues]

I'm sorry but I can't believe that this issue has been opened for more than 3 years now and that there is still no solution 🤷‍♂️

[JEGardner]

I'm sorry but I can't believe that this issue has been opened for more than 3 years now and that there is still no solution 🤷‍♂️

I have to agree. All these micro-optimisations and then you have this which would probably save 100s of kb being sent on every route on most nextjs apps. Don't get it.

[enchorb]

@leerob - any ETA on a solution for this?

[Slowl]

I'm so happy I decided to make the changes early even if it took me some time to do it. It would have taken me more time today.

Crazy to see this is still not resolved.

Next step might be to move the project to Astro 🤔

[gajus]

Randomly stumbled upon this, but I highly recommend ESLint rule that restricts use of barrel files

https://github.com/gajus/eslint-plugin-canonical#no-barrel-import

It is auto-fixable so you don't need to do much to leverage it and it will prevent bloat of your bundle size.

[robert-orlinski]

Hmm, either something was fixed or I don't understand.

I have set up very simple Next.js app using create-next-app (using Next 13.5.6 with pages directory) and created 5 files:

First file (/components/OneComp.tsx):

export const OneComp = () => {
  console.log('first');

  return <div>OneComp</div>
}

Second file (/components/CoupleComp.tsx):

export const Comp1 = () => {
  console.log('fst');

  return <div>OneComp</div>
}

export const Comp2 = () => {
  console.log('sec');

  return <div>OneComp</div>
}

export const Comp3 = () => {
  console.log('thrd');

  return <div>OneComp</div>
}

Third file (/components/Sub/SubComp.tsx):

export const SubComp = () => {
  console.log('sub');

  return <div>OneComp</div>
}

Nested barrel file (/components/Sub/index.ts):

export * from './SubComp'

And the last one - main barrel file (/components/index.ts):

export * from './CoupleComp'
export * from './OneComp'
export * from './Sub'

It looks like this in the end:

---

Then I have imported and used 2 from 5 components imported from the main barrel file into _app.tsx file (similar scenario to the one provided by the author on the whole thread):

import { OneComp, Comp3 } from '@/components'
import '@/styles/globals.css'

export default function App() {
  return (
    <>
      <OneComp />
      <Comp3 />
    </>
  )
}

...and the end file generated after running npm run build and then npm start contains ONLY imported component's code.

This is the content of generated /_next/static/chunks/pages/_app-cfb55d8006062ffe.js file:

(self.webpackChunk_N_E=self.webpackChunk_N_E||[]).push([[888],{6840:function(n,e,_){(window.__NEXT_P=window.__NEXT_P||[]).push(["/_app",function(){return _(3564)}])},3564:function(n,e,_){"use strict";_.r(e),_.d(e,{default:function(){return App}});var c=_(5893);let Comp3=()=>(console.log("thrd"),(0,c.jsx)("div",{children:"OneComp"})),OneComp=()=>(console.log("first"),(0,c.jsx)("div",{children:"OneComp"}));function App(){return(0,c.jsxs)(c.Fragment,{children:[(0,c.jsx)(OneComp,{}),(0,c.jsx)(Comp3,{})]})}_(415)},415:function(){}},function(n){var __webpack_exec__=function(e){return n(n.s=e)};n.O(0,[774,179],function(){return __webpack_exec__(6840),__webpack_exec__(9974)}),_N_E=n.O()}]);

As you can see, it only contains code of OneComp and Comp3 which were imported. You can easily double check that by searching for console.log instances.

Anticipating questions: only this file contains code related to components created by me.

Is there something I don't understand here or what I see here is tree shaking in action? 🤔

[r34son]

Is this issue now fixed with Optimized Package Imports? #54695

Yeah, seems like it helps. I`ve tested with @nextui-org/react and many of internal packages was gone

[jorenbroekema]

For those who have hypothesized that it's a Webpack issue, I cannot reproduce the issue in Webpack alone, treeshaking barrel files seems to work fine there: https://replit.com/@JorenBroekema/barrel-treeshaking

In fact, I've also tested this in Rollup and esbuild and they can also treeshake it just fine. Parcel/Browserify not so much

So seems like a NextJS specific problem.