Help understanding meaning of webpack chunk loading global state and empty chunks

[scameron]

Hello,

I'm looking at the global variable webpack uses for chunk loading and I'm hoping somebody can help me understand what I'm seeing. The variable I'm referring to is the one whose name can (optionally) be defined by output.chunkLoadingGlobal.

There is an element in this global array for every chunk that is loaded. Inside each element are 2 more arrays. The first array to identify the chunk. The second array to list all of the modules that live inside that chunk.

Normally, the "chunk id" array contains only a single element, with the name of the chunk in it. But I found quite a number of cases in my build where the "chunk id" array has multiple elements, with each one referring to a different chunk. For example, this one has 9 elements:

If I open the chunk from the first element, fieldSelection I see that it indeed has this same 9 element array in it , and it contains all of the listed modules:

My first question is: what does it mean when a chunk has a list of other chunks in its id? I'm guessing it means that all of these chunks were found to share the same list of modules?

Now, if I look at the build output on disk, I also find the other 8 chunks also exist (although they are not loaded into the browser at runtime). If I open them, I see they are all basically empty. They all look like this:

Here you can see the chunk id list contains 8 elements instead of 9 elements. The missing element is the fieldSelection one from above that had the actual modules in it. All of the 8 changes are like this, with the 8 element chunk ids (differing only by order) and a single empty function with this same name "?13bc".

Does anybody know why these nearly empty stump-chunks are being generated? What is the empty function for?

In my webpack config I have removeEmptyChunks set to true. Are these not considered empty chunks? That "?13bc" function actually exists in quite a lot of my chunks, empty or not.

If anybody can shed some light on what this all means, I would really appreciate it. I'm trying to reduce the size of my build and runtime footprint by reducing redundancy and duplicated modules, so understanding how this works will help me make progress in figuring the rest of that out.

[alexander-akait]

Looks like they are CSS chunks, right?

[alexander-akait]

@scameron disable minimize - https://webpack.js.org/configuration/optimization/#optimizationminimize

[scameron]

When I was trying to pinpoint the problem, I commented out the entire optimization config, but it didn't help. As an experiment, I just brought it back with only minimize in it, set to false, but I still see the same behavior.

[alexander-akait]

Because this is due fallback, it looks like some modules are just empty,

try:

resolve: {
		alias: {
			"/style.js": false
		}
	},

import * as styles from "/style.js";

And you will get the same output

[scameron]

Yeah, that makes sense. I'm not sure exactly how it is happening in my particular case, but certainly there a lot of complicated aliases and fallbacks and weird exports defined in the packages of the dependencies like readable_stream and others. So it's likely, as you say, that some modules just end up as empty.

But the root question is why, if webpack encounters an empty module, does it still put that module into a chunk and create a require reference to it. The fact that it has that generated module name implies that there must be some special processing happening. So why not just inline an empty function instead of treating the empty module as a real module?

[alexander-akait]

So why not just inline an empty function instead of treating the empty module as a real module?

We do this, but only for ES modules, in some cases we simply delete them (sideEffect free), but to say exactly why in this case it stayed I will need the code. In some cases if it is an asynchronous chunk we need to leave it to put it in the array of loaded modules and understand that we do not need to load it again.