Webpack: An in-depth introduction to SplitChunksPlugin

[Andrei0872]

indepth.dev link.

[berry4u]

great explanation!! Congrats...

[willTerner]

Thank you for your article!

[bigbossx]

awesome!!! this is probably one of the best articles for splitchunk.
btw,do you also have some webpack related articles planned, I'm really looking forward to that, especially like how the min-css-extract-plugin and html-webpack-plugin and enhanced-resolve work.

[Andrei0872]

Hi @visonm, thank you for your kind words!

I have a fairly large number of ideas that could turn into articles(about webpack, RxJS, React and more), however there is very little time for them in this period. The next article, which is almost ready, will be about how React implements the Virtual DOM. After that, it will be really hard to choose, there are so many interesting topics :).

In case it's useful, here is the Notion page where I'm documenting my webpack learning journey(questions, findings, ideas for articles).

[lucasumberto]

Thanks! The article helped me more than webpack documentation! You rock man, keep that way!

[Andrei0872]

Thank you, @lucasumberto! I'm glad it helped!

[hadielyakhni]

Wow! Can't ask for a clearer explanation - the StackBlitz demos and graphs are superb!!
Thank you.

[Andrei0872]

Thank you for your kind words, @hadielyakhni! I'm glad to know they were helpful.

[avallonazevedo]

Certainly, the best article I have ever seen about Webpack split chunks. Thank you for this!

[Andrei0872]

Thank you for your kind words, @avallonazevedo!

[henrikbergstrom]

Great article.
One problem in stackblitz is that node_module folder is not loaded for me.
So build is not working.

[Andrei0872]

Hi @henrikbergstrom, sorry for the late reply.

In the project's readme there are some instructions on how to deal with this problem. Please let me know if they are no longer accurate.

[nghongphuong94]

Your article really helped me sir!

[Andrei0872]

I'm very glad to hear that, @nghongphuong94 !

[likepeach789]

Thank you so much, such a great article! 😁
I have one question regarding the saying:

cacheGroupFoo: {
	// The number of chunks the module must appear in
	minChunks: 3,
   	// Number of bytes put in a chunk(i.e. the sum of the number of bytes for each constituent module)
	// For example, if a chunk contains 2 modules, `x` and `w`, then `nrBytesChunk = nrBytes(x) + nrBytes(w)`.
	minSize: 10,
	// Which modules are to be considered
	modulePathPattern: /node_modules/
}

the x module is required in 3 different chunks, x will be extracted into its own chunk. If there is another module from node_modules, w, which is required in 4 different chunks, then there will be another chunk for the w module, assuming all the other conditions described by the above cache group are fulfilled. If w was required in only 3 chunks, then it would be put in the same chunk as x.

I am confused, if x is 3 and w is 4, they should match the minChunks: 3 right? I thought x and w should be created in the same chunk. Could you please help me to understand it? Much appreciated for your help.

[Andrei0872]

Hi @likepeach789, this is a very interesting question!

Based on my understanding, if, let's say, x is used by a, b, c and w is used by a, b, c, d, then webpack would rather have 2 additional chunks, one only for x and another only for w. In this situation, if x and w would be part of the same chunk, then there will have to be another chunk only for w, because w is used by d. In other words, the w module will be duplicated. I guess it is worse to have the same module in multiple chunks than having multiple chunks but no duplicated modules at all.

The example described above can be found here:

├── node_modules
│   ├── w.js
│   └── x.js
├── src
│   ├── a.js
│   ├── b.js
│   ├── c.js
│   ├── d.js
│   └── index.js
└── webpack.config.js

Also, this is how index.js looks like:

import(/* webpackChunkName: "async-a" */ "./a");
import(/* webpackChunkName: "async-b" */ "./b");
import(/* webpackChunkName: "async-c" */ "./c");
import(/* webpackChunkName: "async-d" */ "./d");

So, a, b, c, and c will be chunks.

The cacheGroupFoo group will create 2 different chunks, one only for x(since it is imported by a, b and c) and one only for w(since it is imported by a, b, c, and d). However, it is true that w fulfills all the conditions in order to be part of x's chunk. Let's see a proof of that.

This is how the cache groups look like after webpack has done its analysis:

Upon expanding the first one, we will see the cache group created because of the w module:

Let's also expand the second one:

Here we see a cache group created because 2 modules, namely x and w, appear in 3 chunks.

In essence, what decides that w appearing in 4 chunks and x in 3 chunks will create 2 different chunks is this piece of logic:

for (const pair of chunksInfoMap) {
  const key = pair[0];
  const info = pair[1];
  if (
  bestEntry === undefined ||
  compareEntries(bestEntry, info) < 0
  ) {
    bestEntry = info;
    bestEntryKey = key;
    }
  }

My understanding is that webpack tries to get find out what is the optimal cache group that it can use to create chunks from.

The compareEntries function describes the criteria of an optimal cache group:

const compareEntries = (a, b) => {
	// 1. by priority
	const diffPriority = a.cacheGroup.priority - b.cacheGroup.priority;
	if (diffPriority) return diffPriority;
	// 2. by number of chunks
	const diffCount = a.chunks.size - b.chunks.size;
	if (diffCount) return diffCount;
       // ...

So, it seems the number of chunks makes the difference. Since the first cache group has 4 chunks, then that is considered the best entry. After chunks have been created, then webpack will try to find the next best entry and so on until no more there are no more cache groups to create chunks from.

[likepeach789]

Thank you so so so so much for such a detailed explanation!!! I will check it and go through the article/code again to better understand how the flow works!!

[tanwarvinay]

Hi, @Andrei0872. The link is not working any more.