Next.js: why commons.xxxxxx.js is so bigger?

[kavience]

Question about Next.js

As you see, I don't know why after I build my project, when I open website, commons.xxxxxx.js is so bigger ?

How can I reduce it ?
Thank you !

[YUFENGWANG]

Try next-bundle-analyzer

[jeremy-coleman]

webpack by default will look for es modules inside node_modules, nextjs disables this, so libraries that are normally tree shakable are no longer tree shakable using next's defaults. Which kind of makes sense because its gotta exec the code inside node.

Instead of trying to make next's mysterious config and build work for you , try using rollup as an intermediate step and only let nextjs see single components per page (which you import from the rollup output) . it adds some complexity but has been worth it , at least for my use case. rollup has two cool options, 'preserveModules' and inlineDynamicImport (helps with reshaping if you need to).

[kavience]

@YUFENGWANG @jeremy-coleman
Thank guys reply, I think maybe I import many packages , therefore after nextjs builded, commons.xxxxx.js is too bigger . but I find another way to solved it.

by compressionjs the commons.xxxxx.js is less then 1.5 M, before is 4.5 M .

[timneutkens]

webpack by default will look for es modules inside node_modules, nextjs disables this, so libraries that are normally tree shakable are no longer tree shakable using next's defaults. Which kind of makes sense because its gotta exec the code inside node.

This is incorrect. As you can see here: https://github.com/zeit/next.js/blob/canary/packages/next/build/webpack-config.ts#L160

browser and module are preferred and tree shaking works.

Instead of trying to make next's mysterious config and build work for you , try using rollup as an intermediate step and only let nextjs see single components per page (which you import from the rollup output) . it adds some complexity but has been worth it , at least for my use case. rollup has two cool options, 'preserveModules' and inlineDynamicImport (helps with reshaping if you need to).

The config is available here: https://github.com/zeit/next.js/blob/canary/packages/next/build/webpack-config.ts

I would highly recommend not adding a needless intermediate steps.
This recommendation might be useful when you're building a completely separate npm library of components. But in that case it's probably better to use microbundle.

---

@kavience you might want to try out https://github.com/zeit/next.js/pull/7696

module.exports = {
  experimental: {
    granularChunks: true
  }
}

[slorber]

@kavience or anyone else, any feedback on granular chunks?