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)

[ivan-kleshnin]

Please let us know if https://nextjs.org/docs/app/api-reference/next-config-js/optimizePackageImports resolves your issue with regards to proper tree shaking with Typescript barrel files. If yes, we will proceed with moving this issue to Discussions.

The very idea that we have to manually list libraries that were previously tree-shaken automatically is... not inspiring.

[samcx]

@ivan-kleshnin Can you share a showcasing where it was done automatically previously so we can take a closer look?

[gajus]

@ivan-kleshnin out of curiosity, why did you thumbs down ESLint plugin I suggested?

#12557 (comment)

It is working great for us

[jorenbroekema]

Regardless of whether it was or wasn't done automatically previously, can you explain why it makes sense to manually specify a list of package to optimize? Isn't it always a good default to optimize dependencies? From the docs, it is not clear in what scenario it is helpful to "not optimize packages".

From what I can tell, the default should be to optimize/treeshake all dependencies, at least for production, with perhaps an opt-out, although I don't see a reason for that either. Again, maybe I'm missing some context but this seems to me like really awful API design when considering the principle of "choose good defaults" and "allow users to opt into necessary exceptions".

[jorenbroekema]

@ivan-kleshnin out of curiosity, why did you thumbs down ESLint plugin I suggested?

#12557 (comment)

It is working great for us

I'm not the downvoter but couple of reasons:

1. You're linting plugin fixes barrel files, great, but that only helps for my dependencies exporting barrel files if I let ESLint lint my dependencies, and then it fixes my dependencies code which I'm not happy to commit to git, personally
2. A linting plugin as a solution to the problem that Next's default behavior with regards to treeshaking barrel files sucks is not really a good solution, it's a workaround. Maybe a useful one at that, but I get the downvote, I personally don't see it as an acceptable workaround as it introduces another devdependency -> arguably tech debt.

[ivan-kleshnin]

@ivan-kleshnin out of curiosity, why did you thumbs down ESLint plugin I suggested?
#12557 (comment)
It is working great for us

Because that plugin simply "Restricts the use of barrel files". I don't see barrel files as something bad that should be avoided, me/my teams in the present/past heavily used them outside of NextJS context, with great success. They are convenient, and I'm not aware of any cons, except that they cripple NextJS... So why I should lint myself against NextJS issue? 🤔 If they aren't going to fix... ok, we have a growing list of complaints against this framework and React anyway, might be a good final reason to switch out.

[IonelLupu]

I came across this issue when using react-aria-components. When using just a simple <Button>, the entire react-aria-components library is imported.

While reading this thread, I saw this issue linked above: #44039

It seems when using use client in your page, makes the builder tree-shake correctly. Not sure why is that. Buuuut, the issues don't stop there. If you use the <Button> on page A and the <Select> on page B, the bundle analyzer shows page A imports the <Select> component EVEN if page A doesn't use the <Select> component. It seems it combines all of the react-aria-components files into one big import in EVERY SINGLE PAGE.

I detailed the issue here: #60206

[samcx]

...They are convenient, and I'm not aware of any cons

@ivan-kleshnin As far as I'm aware, there is a cost to using barrel files, which is why we recently introduced optimizePackageImports.

I agree that it is not ideal to manually have to add packages to optimizePackageImports if the package in question is not already manually listed here. →

next.js/packages/next/src/server/config.ts

Lines 710 to 765 in 12e8881

	...new Set([
	...userProvidedOptimizePackageImports,
	'lucide-react',
	'@headlessui/react',
	'@headlessui-float/react',
	'@heroicons/react/20/solid',
	'@heroicons/react/24/solid',
	'@heroicons/react/24/outline',
	'@visx/visx',
	'@tremor/react',
	'rxjs',
	'@mui/material',
	'recharts',
	'@material-ui/core',
	'react-use',
	'@material-ui/icons',
	'@tabler/icons-react',
	'mui-core',
	// We don't support wildcard imports for these configs, e.g. `react-icons/*`
	// so we need to add them manually.
	// In the future, we should consider automatically detecting packages that
	// need to be optimized.
	'react-icons/ai',
	'react-icons/bi',
	'react-icons/bs',
	'react-icons/cg',
	'react-icons/ci',
	'react-icons/di',
	'react-icons/fa',
	'react-icons/fa6',
	'react-icons/fc',
	'react-icons/fi',
	'react-icons/gi',
	'react-icons/go',
	'react-icons/gr',
	'react-icons/hi',
	'react-icons/hi2',
	'react-icons/im',
	'react-icons/io',
	'react-icons/io5',
	'react-icons/lia',
	'react-icons/lib',
	'react-icons/lu',
	'react-icons/md',
	'react-icons/pi',
	'react-icons/ri',
	'react-icons/rx',
	'react-icons/si',
	'react-icons/sl',
	'react-icons/tb',
	'react-icons/tfi',
	'react-icons/ti',
	'react-icons/vsc',
	'react-icons/wi',
	]),
	]

Ideally, we just automatically detect packages that need to use optimizePackageImports, so the user doesn't have to even concern themselves with this. Will be discussing this with the team to see how we can achieve that!

[IonelLupu]

...They are convenient, and I'm not aware of any cons

@ivan-kleshnin As far as I'm aware, there is a cost to using barrel files, which is why we recently introduced optimizePackageImports.

I agree that it is not ideal to manually have to add packages to optimizePackageImports if the package in question is not already manually listed here. →

next.js/packages/next/src/server/config.ts

Lines 710 to 765 in 12e8881

	...new Set([
	...userProvidedOptimizePackageImports,
	'lucide-react',
	'@headlessui/react',
	'@headlessui-float/react',
	'@heroicons/react/20/solid',
	'@heroicons/react/24/solid',
	'@heroicons/react/24/outline',
	'@visx/visx',
	'@tremor/react',
	'rxjs',
	'@mui/material',
	'recharts',
	'@material-ui/core',
	'react-use',
	'@material-ui/icons',
	'@tabler/icons-react',
	'mui-core',
	// We don't support wildcard imports for these configs, e.g. `react-icons/*`
	// so we need to add them manually.
	// In the future, we should consider automatically detecting packages that
	// need to be optimized.
	'react-icons/ai',
	'react-icons/bi',
	'react-icons/bs',
	'react-icons/cg',
	'react-icons/ci',
	'react-icons/di',
	'react-icons/fa',
	'react-icons/fa6',
	'react-icons/fc',
	'react-icons/fi',
	'react-icons/gi',
	'react-icons/go',
	'react-icons/gr',
	'react-icons/hi',
	'react-icons/hi2',
	'react-icons/im',
	'react-icons/io',
	'react-icons/io5',
	'react-icons/lia',
	'react-icons/lib',
	'react-icons/lu',
	'react-icons/md',
	'react-icons/pi',
	'react-icons/ri',
	'react-icons/rx',
	'react-icons/si',
	'react-icons/sl',
	'react-icons/tb',
	'react-icons/tfi',
	'react-icons/ti',
	'react-icons/vsc',
	'react-icons/wi',
	]),
	]

Ideally, we just automatically detect packages that need to use optimizePackageImports, so the user doesn't have to even concern themselves with this. Will be discussing this with the team to see how we can achieve that!

@samcx optimizePackageImports doesn't work in my case when using react-aria-components. I detailed the issue in the comment above. Using Vite works correctly. Also, using "use client" kinds gives okish results, but there is a bigger problem when you have multiple pages. Again? Detailes in the discussion I listed above

[samcx]

@IonelLupu Thank you for re-iterating your issue involving react-aria-components and creating a detailed discussion post. I have created #60246 from your discussion post and will be taking a look!

[samcx]

Update: there was a fix for the above issue that entailed importing direct Client Components in Server Components.

#60246 (comment)

[tocosastalo]

Maybe this isn't related, but I came across this issue when using plaiceholder, which is supported only in server components.

I have barrel/index file which re-exports both server and client "elementary" components. During development when some page imports client component from the barrel file, the app crashes on error "ReferenceError: require is not defined". So it looks like the server component is automatically imported/loaded and gets into the browser despite the fact that it is marked as server component (without "use client" at the top) and is not used anywhere on the page.

Simplified components are:

// ServerImageWithBlur.tsx
import { getPlaiceholder } from "plaiceholder"

export const ServerImageWithBlur = async (props: ImageProps) => {
  const { base64, img } = await getPlaiceholder(props.src)
  return <Image placeholder="blur" blurDataURL={base64} {...props} {...img} />
}

// Navbar.tsx
"use client" 

export const Navbar = () => {
  return <div>...</div>
}

// index.ts
export { ServerImageWithBlur } from "./ServerImageWithBlur"
export { Navbar } from "./Navbar"

Error:

Unhandled Runtime Error
ReferenceError: require is not defined

When I comment the re-export of the server component from index.ts, the application works.

// index.ts
// export { ServerImageWithBlur } from "./ServerImageWithBlur"
export { Navbar } from "./Navbar"

[RadovanPelka]

Same problem... it looks like when everything is in index.ts, it automatically gets to the client.

[samcx]

@tocosastalo Can you create a new separate bug report so we can take a look?

In the meantime, I will be moving this over to Next.js discussions, since we have veered from the original issue posted back in 2020.

[threehams]

optimizePackageImports is currently very aggressive in caching the contents of index.ts files within a project, in the dev server and builds, even going as far as persisting contents across production builds. Reported here:
#65630

[SlimDaddy228]

#69532