transpilePackages doesn't tree-shake barrel export in turborepo
Link to the code that reproduces this issue
https://github.com/raphaelbadia/barrel-exports-transpile-module-not-treeshaking
To Reproduce
- clone the repository and run
yarn buildin the root repository
Current vs. Expected behavior
Following the steps from the previous section, I expected the build output to be very light for the / (home page), something like : λ / 137 B 79.4 kB.
However I instead saw : λ / 13.7 kB 92.9 kB
Three tabs opened, in the client.html one, I clicked the left drawer, chose app/page as the chunk to explore and saw packages that aren't used:
Verify canary release
- [X] I verified that the issue exists in the latest Next.js canary release
Provide environment information
yarn run v1.22.19
$ /Users/raphael/code/billiv/turbotranspilepkg/node_modules/.bin/next info
Operating System:
Platform: darwin
Arch: x64
Version: Darwin Kernel Version 22.3.0: Mon Jan 30 20:39:46 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T6020
Binaries:
Node: 18.16.0
npm: 9.5.1
Yarn: 1.22.19
pnpm: 8.6.8
Relevant Packages:
next: 13.5.3-canary.3
eslint-config-next: N/A
react: 18.2.0
react-dom: 18.2.0
typescript: 4.9.5
Next.js Config:
output: N/A
✨ Done in 2.67s.
Which area(s) are affected? (Select all that apply)
SWC transpilation
Additional context
I was trying to understand why my website is so heavy, and decided to create a new project from scratch. I realised that the problem appears as soon as I add a library to the UI package.
Same here. Moreover, it doesn't tree shake even with "ordinary-non-barrel" exports.
// lib/client.tsx
'use client'
export function ClientComponent() {...}
// lib/server.tsx
export function ServerComponent() {...}
// lib/index.tsx
export { ClientComponent } from './client'
export { ServerComponent } from './server'
Then, in the app:
// app/page.tsx
import { ServerComponent } from "./lib";
export default function Page() {
return <ServerComponent />;
}
ClientComponent was not tree-shaked and still in the bundle.
@mehulkar could we get some input from the Next.js team on this? Looks like it's a pretty big issue, making some internal libs completely unusable.
Thanks in advance 😄
I can confirm this issue still exists on Next v13.5.5
Same here
this exists on 14.01 as well
Although I believe I've seen @shuding recommending against it for now on Twitter, I've had success using the experimental optimizePackageImports for my turborepo packages for Next 13.5.7 and later
/** @type {import('next').NextConfig} */
const nextConfig = {
transpilePackages: ["ui"],
experimental: {
optimizePackageImports: ["ui"]
}
}
module.exports = nextConfig
If your ui package imports any other package with a lot of modules, you might also need to put them in optimizePackageImports
The number of modules for some pages decreased by over 10k for us
Although I believe I've seen @shuding recommending against it for now on Twitter, I've had success using the experimental
optimizePackageImportsfor my turborepo packages for Next 13.5.7 and later/** @type {import('next').NextConfig} */ const nextConfig = { transpilePackages: ["ui"], experimental: { optimizePackageImports: ["ui"] } } module.exports = nextConfigIf your
uipackage imports any other package with a lot of modules, you might also need to put them inoptimizePackageImportsThe number of modules for some pages decreased by over 10k for us
optimizePackageImports not make sense for babel users because it require swc :(
Although I believe I've seen @shuding recommending against it for now on Twitter, I've had success using the experimental
optimizePackageImportsfor my turborepo packages for Next 13.5.7 and later/** @type {import('next').NextConfig} */ const nextConfig = { transpilePackages: ["ui"], experimental: { optimizePackageImports: ["ui"] } } module.exports = nextConfigIf your
uipackage imports any other package with a lot of modules, you might also need to put them inoptimizePackageImportsThe number of modules for some pages decreased by over 10k for us
This partially worked for me but I ended up having some components that still imported server specific functions. I ended up going this (long) route I found on the turborepo discord server. Server components header, main-layout and footer are packaged then properly separated. I could referenced the "src" folder directly rather than creating an exports but I had a lot of other code nested in that folder and this approach just seemed cleaner.
{
"name" : "@acme/chat-ui",
"exports": {
"./configs": "./exports/configs.tsx",
"./utils": "./exports/utils.ts",
"./hooks": "./exports/hooks.tsx",
"./context": "./exports/context.tsx",
"./chat": "./exports/chat.tsx",
"./sidebar": "./exports/sidebar.tsx",
"./header": "./exports/header.tsx",
"./main-layout": "./exports/main-layout.tsx",
"./footer": "./exports/footer.tsx"
},
"typesVersions": {
"*": {
"*": [
"exports/*"
]
}
}
Used like this:
import { Chat } from '@acme/chat-ui/chat'
We're facing what could very well be the same issue on next 14.2.6 with turbo enabled. experimental.optimizePackageImports and transpilePackages don't seem to change anything. Our index page size is currently 3.77MB (4.79MB first load) and that's just wrong.
During development, no matter if turbo is enabled or not, the next-server process can reach usage of 4GB of ram just compiling he index page. We attribute this to Next loading (very inefficiently) our entire library into memory. Some of our developers have been impacted really heard due to this issue.
We've spent the entire day removing all our barrel exports, updating imports and testing but we can't seem to fix this problem any way.
We'd really appreciate some input as to how we're supposed to debug these issues and how to reduce the 4gb memory usage while in development.
If you have something like a UI library with many, many components, what do you replace barrel files with? How do you organize exports? I feel like I'm missing something obvious.
You do it the ugly way, like that... 🥲