SplitChunksPlugin SplitChunksPlugin SplitChunksPlugin SplitChunksPlugin SplitChunksPlugin SplitChunksPlugin SplitChunksPlugin SplitChunksPlugin SplitChunksPlugin SplitChunksPlugin SplitChunksPlugin SplitChunksPlugin
Modify chunkName with Magic comment
The meaning of this writing is a lodash library, introduced asynchronous, when the code segment, packaged the partition of library chunkName for lodash (file name)
The reason is that we used dynamic-import-webpack before, which is an unofficial plug-in. The unofficial plug-in does not support the writing method of Magic Comment, so we need to replace this plug-in
So we need to replace this plugin with an official plugin. Remove it from package.json
Get rid of it in.babelrc
Change dynamic-import-webpack to official plugin NPM i@babel /plugin-syntax-dynamic-import -d. Babelrc
Repackage and find that Magic Comment works, but lodash package becomes verders-lodash.js. How to make it lodash.js?
Check the official WebPack documentation and find SplitChunksPlugin. There are many splitChunk configurations
We will temporarily configure splitChunks like this, repackage them, and find that the file name of the splitChunks package is lodash.js
Note: splitChunks are configured by default if they are not configured
Splitchunks. chunks have async (asynchronous), INITIAL (synchronous), and all (asynchronous and synchronous) tests: Set chunks to Async and comment CodeSplitting. Js on the asynchronous import code, freeing the synchronous import code
Package, find no lodash.js, sync introduced code without code splitting
We then set chunks to ALL (both asynchronous and synchronous import modules will be code split) and package again
There is still no Lodash.js, no code splitting performed
This is because cacheGroups needs to be configured
Again packaged, vendors~main.js appears, which packs LoDash into this file, indicating that code splitting has been performed
It is called verdors-main.js, which means code split, dividing LoDash into vendors groups, and the imported entry file is packaged with a chunkName of main.js
We can also configure filename to freely set the filename of the code split package output
Note: Chunks and cacheGroups are used together
② If minSize is larger than the number of bytes, code splitting will be performed (too much code splitting will cause too many HTTP requests, so minSize needs to be set).
③ If false is set to default groups in cacheGroups, then non-node_modules (vendors groups that don’t fit vendors groups) don’t know how to code split, so it should be configured
This generates default~main.js, which means code split, and divides loDash into the default group. Meanwhile, the imported import file is packaged with the chunkName of main.js, which can also set the output filename
④maxSize, if this size is exceeded, the code will be more fine code segmentation
(5) minChunks: code segmentation is performed when a module has been used by at least how many chunks (js files generated by packaging)
(6) maxAsyncRequests: How many modules can be loaded simultaneously (that is, the first five modules can be partitioned and the remaining five modules can no longer be partitioned)
⑦maxInitialRequests, the number of entry files before the code split, more than three entry files no code split (reduce the number of HTTP requests)
8. AutomaticNameDelimiter, the file is generated with a file name connector, such as vendors~main.js
⑨name: true: indicates that the file name in cacheGroups is valid
10)cacheGroups, don’t rush to bundle up vendors’ unification and vendors’ default unification in case of code splitting
11) Priarity represents the priority, that is, if a module conforms to both default and vendors, and the vendors have a higher priority, the module will be packaged into vendors first
12)reuseExistingChunk
If A uses B again, normally A is packaged into vendors, and B will also be packaged into vendors, but when b is packaged, it is found that B has been introduced before and packaged into commin, ReuseExistingChunk: True, THEN B does not package again into vendors, but uses ReuseExistingChunk directly: true does not repackage, and is used directly if it encounters packaged modules
