Code segmentation itself has nothing to do with webpack, but since using webpack can implement code segmentation very easily, when talking about code segmentation, you will first think of using webpack to implement it.
It is used in webpackSplitChunksPluginTo achieve it, becauseSplitChunksPlugin There are many configuration parameters, so let’s sort out these configuration parameters.
The default configuration parameters on the official website are as follows:
= {
//...
optimization: {
splitChunks: {
chunks: 'async', // When splitting code, it takes effect on asynchronous code. All: all codes are valid, initial: synchronous code is valid minSize: 30000, // Code segmentation is the smallest module size, and the imported module is greater than 30,000B before code segmentation is performed maxSize: 0, // The maximum module size of code segmentation is required. If the code is larger than this value, the default value is generally used. minChunks: 1, // Code segmentation is performed when the number of times introduced is greater than or equal to 1 maxAsyncRequests: 6, // The maximum number of asynchronous requests, that is, the maximum number of modules loaded simultaneously maxInitialRequests: 4, // The entry file is divided into up to 4 js files for code division automaticNameDelimiter: '~', // Connector when file generation automaticNameMaxLength: 30, // Maximum length of automatically generated file names cacheGroups: {
vendors: {
test: /[\\/]node_modules[\\/]/, // The module located in node_modules is used to split the code priority: -10 // Determine which group to package according to priority, for example, a module in node_modules for code }, // Split, satisfy both vendors and default, then it will be packaged into the vendors group according to priority. default: { // No test indicates that all modules can enter the default group, but be aware that it has a lower priority. priority: -20, // Determine which group to package into based on priority and package into a group with higher priority. reuseExistingChunk: true // // If a module has been packaged, then ignore the module when packaging again }
}
}
}
};
A few additional points:
In the grouping, you can artificially specify the name of the packaged file and add it in the vendor group filename = "" After that, the names of the files after packaging in the vendor group are all .
reuseExistingChunk Example explanation:
// import b from './b'; // import a from './a'; import b from './b';
In the above code, the a module is introduced when executing import a from './a'. Since the b module is used in the a module, the b module is also introduced. When executing import b from './b' again, since the b module has been packaged, the b module will be ignored. This is the function of reuseExistingChunk: true.
How should I implement it if I want to package two modules into a file?
cacheGroup can realize this requirement. Assuming there are two modules, module1 and module2, and they both meet the vendor group, then when performing code segmentation, module1 will be placed in the CacheGroup, then module2 will be placed in the cacheGroup, and finally the two will be placed in the vendor group to generate a file.
This is the end of this article about the detailed explanation of SplitChunksPlugin configuration parameters in Webpack. For more related Webpack SplitChunksPlugin configuration content, please search for my previous articles or continue browsing the related articles below. I hope everyone will support me in the future!