Open raphaelbadia opened 11 months ago
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
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 inoptimizePackageImports
The 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
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 inoptimizePackageImports
The 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.
Link to the code that reproduces this issue
https://github.com/raphaelbadia/barrel-exports-transpile-module-not-treeshaking
To Reproduce
yarn build
in the root repositoryCurrent 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![CleanShot 2023-09-25 at 11 05 52@2x](https://github.com/vercel/next.js/assets/1901628/fa1ea19e-7ce5-42f2-8224-149e158b6eca)
client.html
one, I clicked the left drawer, choseapp/page
as the chunk to explore and saw packages that aren't used:Verify canary release
Provide environment information
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.