Webpack 4 – Mysterious SplitChunks Plugin

SplitChunksPlugin is added to the commonChunkPlugin. For this plugin, the options are ‘initial’, ‘async’, and ‘all’. I don’t think most people who are new to WebPack 4 have a good understanding of the differences between these values. This article explains in detail what each of these values means.

This is my rough attempt to understand and help you use the SplitChunksPlugin option with a common example.

As an early enthusiast, I tried to understand the magic behind code-spliting. The documentation says that splitChucnks accepts ‘initial’, ‘async’, and ‘all’. I was a little confused, which heightened my curiosity.

I dug into the documentation’s Github history and WebpackOptions profile and found that

"There are3Initial values possible ", ""asyncWhen configured the optimization only selects initial chunks, - Github History "Select chunks.for~ ~ shared modules (defaults to)async", "initial" and "all" requires adding these chunks to the HTML) "-- WebpackOptions SchemaCopy the code

The idea here is to have two entry files, a.js and B.JS, and then reference the same node_modules. Some of these modules will be introduced dynamically to verify code-spliting behavior.

We use the Webpack Bundle Analyzer Plugin to help us understand how our node_modules are divided.

a.js:

Only Lodash is introduced dynamically

b.js:

The main reason I chose this configuration is to understand how the Webpack configuration behaves when there are common libraries

  1. One entry file is dynamically introduced, the other is not – React
  2. Dynamically introduce -lodash in both entry files
  3. Do not dynamically introduce – jquery in either entry file

We will leave these files unchanged and change the WebPack configuration with the chunks value.

1. Chunks: async – Optimization over async module

Chunks: ‘async’ tells webPack

“Hey, webpack! I only care about the optimization of dynamically imported modules. You can keep non-dynamic modules.”

Now, let’s take a step-by-step look at what’s going on, okay

  • Webpack will extract React from B.JS and move it to a new file, but leave react in A.JS unchanged. This optimization only applies to dynamic modules, import(‘react’) declarations generate separate files, import ‘react’ does not
  • Webpack extracts lodash from A.js and moves it to a new file, which is also referenced by B.JS
  • Jquery is not optimized here, although both A.js and B.JS are referenced

2. Chunks: “initial” – Optimization over Sync Module

“Hey, webpack! I don’t care about dynamically imported modules, you can create separate files for each module. However, I want to put all the non-dynamically imported modules in a bundle, and although they need to introduce other non-dynamically imported blocks, I’m ready to share and block my non-dynamically imported modules with other files.”

Now, let’s take a step-by-step look at what’s going on, okay

  • React in A.JS will be moved to node_vendors~ a.Bundle.js, and react in B.JS will be moved to 0.bundle.js
  • Lodash in a.js and B.JS will be moved to 1.bundle.js. Why is that? This is a dynamically introduced module
  • Jquery is a non-dynamically imported public module, and will be moved to node_VENDORS ~a~ b.Vendors. Js, shared by both A.js and B.JS

3. chunks : ‘all’ — Optimization over Async and Sync Module

Chunks: ‘all’ tells Webpack

“Hey, webpack! I don’t care if this is a dynamically introduced module or a non-dynamically introduced module. Both of them are optimized. But make sure that…… You’re smart enough to do it.”

Now, let’s take a step-by-step look at what’s going on, okay

  • React is a non-dynamically introduced module in A. JS, but dynamically introduced in B. JS. Therefore, it goes to a single file, 0.bundle.js, which will be referenced by both.
  • Lodash is introduced dynamically in both files, so it obviously gets a separate file, 1.bundle.js
  • Jquery is non-dynamically imported, so it goes to the common shared module node_VENDORS ~a~ b.Vendors. Js, and will be referenced by both.

discuss

The first translation, there are many places not in place, welcome correction. Address github.com/liuhanqu/bl…