How does tree shaking work with this setup? about nextjs-monorepo-example

[belgattitude]

And deleting it breaks the build.

If you're on nextjs 10.2+, you can replace it by

const nextConfig = {
  experimental: {
    externalDir: true,
  },
};
export default nextConfig;

See https://github.com/belgattitude/nextjs-monorepo-example#step-33-next-config. It basically does the same but with support for css files too. In my experience it does not affect the bundle

I replaced that config for next-transpile-modules, and the bundle stayed the same.

The experimental.externalDir (or the previous webpack rule you had) is enough. No need for ntm in general. In my experience it does not affect the bundle

There's probably something else to find out

[lucas-janon]

externalDir works perfectly! Thanks.

Yes, we're using a bundle analyzer, and the only way to prevent importing a lot of unneeded modules on _app.ts seems to be not importing from the barrel file:

With barrel file:

Without it:

[lucas-janon]

Yes! I ended up changing the file from Javascript to Typescript and using import, it previously was a js file because we used to import it from next.config.js, that change reduced the bundle by ~190kb.

We don't build the packages for the frontend, we just build one of them for the backend, so I'm not sure what's happening with sideEffects, honestly, the combination of multiple technologies + versions + configs to make the monorepo setup work, make the debugging process a bit complicated, mostly since learning about the underlying tech to make the monorepo work competes against learning/improving customer-facing tech, that's why I really appreciate what you did with this open-source monorepo, it makes it much smoother.

[belgattitude]

That explains yes. Thank for sharing the explanation. Nice

[belgattitude]

We are having issues with tree shaking and barrel (index.ts) files in our setup, we have 3 big shared libraries and we're getting (a lot) more code than we need from them on every Next.js page.

If you suspect something linked to the barrel, I would check if there's no circular deps

ie:

index.ts

export { compOne } from "./compOne";
export { compTwo } from "./compTwo";

compTwo.ts

❌ import { compOne } from './index.ts';  // or equivalent to import compOne from './';  
✅ import { compOne } from './compOne'; // that would fix circular deps that webpack won't really digest 

export compTwo = () => compOne(12) * 2;

So I'm curious to know what config is enabling tree shaking to work properly, even without needing "sideEffects": false in the package.json files.

sideEffects is the thing yes... at least when the lib/package is built (prebuild, preconstructed) and published before getting consumed (by nextjs or ...).

In the nextjs-monorepo-example we do not (but we could)... so sideEffect to false won't change anything. Packages are consumed without prior build.

Let me know if helps a bit. Cause I'm not sure I have enough info 😄

[lucas-janon]

Thanks for the answer, we'll check for circular deps!
For now, we were able to reduce the bundle size by using nested imports instead of the barrel file.
We're also consuming the packages directly from their source (using Vercel's monorepo support and Typescript), and checking our config I noticed that we still have this in next.config.js:

    const resolvedBaseUrl = path.resolve(config.context, "../../");

    config.module.rules = [
      ...config.module.rules,
      {
        test: /\.(tsx|ts|js|mjs|jsx)$/,
        include: [resolvedBaseUrl],
        use: options.defaultLoaders.babel,
        exclude: (excludePath) => /node_modules/.test(excludePath),
      },
    ];

And deleting it breaks the build. I think I took that from a previous version of this repo because the current one doesn't have it, I'm curious if it affects the bundle or not.

This is the error we get after deleting it:

You may need an appropriate loader to handle this file type, currently, no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
| import { ErrorBoundaryModal } from "./ErrorBoundaryModal";
|
> export class ErrorBoundary extends React.Component<UserDataProps, ErrorProps> {
|   state = {
|     error: null,

EDIT:
I replaced that config for next-transpile-modules, and the bundle stayed the same.

[belgattitude]

Have you tried a bundle-analyzer ?

nextjs-monorepo-example/apps/web-app/package.json

Line 39 in 357ed48

"bundle:analyze": "cross-env ANALYZE=true yarn build",

[belgattitude]

I'm curious now. Webpack 5 right? Not swc ?

What version of nextjs are you using?

Ps: worth to disable this if set

nextjs-monorepo-example/apps/web-app/next.config.js

Line 88 in 0552c84

swcMinify: true,

[lucas-janon]

Ok, mystery solved!

The issue was caused by a require statement (pointing to one of our shared libs) in a config file that was imported in _app.tsx, but the crazy thing is that our setup is affected by setting "sideEffects": false in the libs package.json files.

We have 3 shared libs.

If I set "sideEffects": false in all of them:

If I don't:

[belgattitude]

Nice.

Have you tried to change the require into an import ? Out of curiosity...

I didn't know package.json would be read when using aliases. So you build your packages prior to consume them?