Webpack 4: Code Splitting, Chunk Graph and the splitChunks Optimization Significant changes made to upgrade from webpack3 to webpack4

Webpack4 makes some significant improvements to the Chunk diagram and adds a new optimization for chunk splitting (an improvement over the CommonsChunkPlugin)

Let’s look at some of the drawbacks of the old diagram

In the old diagram, chunks were connected to other chunks through parent-child relationships and chunks containment modules

When a chunk has multiple parent nodes, we can assume that at least one parent node has been loaded when the chunk is loaded. This information can be used to optimize, for example, when a chunk’s module is available at all parent nodes, it can be removed from chunk because it must have been successfully loaded.

These chunks are loaded in parallel when the list of chunks is referenced at the entry point or asynchronous split point.

This type of diagram makes it very difficult to separate chunks, for example using the CommonsChunkPlugin there is a problem when you remove one or more chunks and place them in a new chunk that needs to be reconnected to the diagram, but how? As the parent or child of the old Chunk? CommonsChunkPlugin adds it as a parent, but this is technically wrong and has a negative impact on other optimizations (the parent information is inaccurate)

The new chunk diagram introduces a new object: ChunkGroup, a ChunkGroup containing multiple chunks

Referencing a single ChunkGroup at an entry point or asynchronous split point means that all chunks contained by the ChunkGroup are loaded in parallel. A chunk can be referenced in multiple chunkgroups (but not loaded multiple times)

Instead of using parent-child relationships to associate chunks, they are now associated through chunkgroups

Now that chunks are understood, new chunks are added to all ChunkGroups that contain the original chunk without negatively affecting the parent hierarchy.

Now that this problem has been fixed, we can start using chunk separation more often, and we can split chunks at will without worrying about the chunk map being broken

The CommonsChunkPlugin has a number of problems:

  1. We’ll download some code that we don’t need
  2. In asynchronouschunksThe bottom is inefficient
  3. It’s a little harder to use
  4. It’s a little bit harder to understand in practice

So a new plugin was born: SplitChunksPlugin

It automatically identifies modules that should be partitioned through heuristics, and splits chunks using module repeat counts and module categories (such as node_modules)

Here’s a metaphor for both. CommonsChunkPlugin is like :” Create a chunk and move all the modules matching minChunks into the new chunk “, SplitChunksPlugin is like :” This is heuristics, “Here are the heuristics, make sure you fullfil them “(imperative vs. declarative)

SplitChunksPlugin also has some nice properties:

  1. It will never download unwanted modules (as long as you don’t enforce them by namechunkMerged)
  2. In asynchronouschunksIt’s also efficient
  3. Default is asynchronouschunksMode split
  4. Easier to use
  5. Don’t depend onchunkfigure
  6. Most are configured automatically

Here are a few examples from SplitChunksPlugin. These examples show only the default behavior, with additional configurations having more personalized options

Note: You can configure this via optimization.splitchunks. These examples illustrate some content about the chunk, by default it only applies to asynchronous chunk, but using optimization. SplitChunks. Chunks: “all” to configure, suitable for all types of documents (synchronous and asynchronous chunk)

Note: We assume that each external library used here is larger than 30KB, because code optimizations only take effect after that size.

Vendors

chunk-a: react, react-dom, some components

chunk-b: react, react-dom, some other components

chunk-c: angular, some components

chunk-d: angular, some other components

Webpack will automatically create two vendors chunks, resulting in the following:

vendors~chunk-a~chunk-b: react, react-dom

vendors~chunk-c~chunk-d: angular

chunk-a to chunk-d: Only the components

Vendors overlap

chunk-a: react, react-dom, some components

chunk-b: react, react-dom, lodash, some other components

chunk-c: react, react-dom, lodash, some components

Webpack also creates two vendors Chunks, resulting in the following:

vendors~chunk-a~chunk-b~chunk-c: react, react-dom

vendors~chunk-b~chunk-c:lodash

chunk-a to chunk-c: Only the components

Shared module

chunk-a: vue, some components, some shared components

chunk-b: vue, some other components, some shared components

chunk-c: vue, some more components, some shared components

Assuming the shared component is larger than 30KB, Webpack will create one Vendor Chunk and one Commons chunk, resulting in the following:

vendors~chunk-a~chunk-b~chunk-c: vue

commons~chunk-a~chunk-b~chunk-c: some shared components

chunk-a to chunk-c: Only the components

When the size of these shared components is less than 30KB, Webpack specifically copies the modules to chunk-a chunk-b chunk-c files. They argue that the overall effect of the load volume reduction by separation is not the same as the cost of an additional load request.

Multiple shared modules

chunk-a: react, react-dom, some components, some shared react components

chunk-b: react,react-dom, angular, some other components

chunk-c: react,react-dom, angular, some components, some shared react components, some shared angular components

chunk-d: angular, some other components, some shared angular components

Webpack will create two Vendors Chunks and two Commons chunks, resulting in the following:

vendors~chunk-a~chunk-b~chunk-c: react, react-dom

vendors~chunk-b~chunk-c~chunk-d: angular

commons~chunk-a~chunk-c: some shared react components

commons~chunk-c~chunk-d: some shared angular components

chunk-a to chunk-d: Only the components

Note: since the chunk name includes all the original name of the chunk, therefore it is recommended to use in the long-term production version does not include the file name of cache [name], or through optimization. SplitChunks. Name: false close name generation. This way, new references are added in subsequent development without changing the file name.

For any optimization suggestions in this paper, you can scan the following TWO-DIMENSIONAL code to discuss, but also hope that you pay more attention to, will send some original articles from time to time