Normally we have our own WebApp code and third-party libraries consisting of our own code will often change, and third-party libraries unless there is a larger version of the upgrade, or will not change, so the first tripartite library and our code needs to be packaged separately, we can set a longer time to cache strong third-party libraries, so you do not frequently request code of the third-party libraries.
So how to extract a third party library? In webpack4.x in, SplitChunksPlugin plug-in replaces the CommonsChunkPlugin plug-in module to perform common extraction, we can configure SplitChunksPlugin were unpacking operations.
SplitChunksPlugin a schematic configuration as follows:
optimization: {
splitChunks: {
chunks: "initial", // 代码块类型 必须三选一： "initial"（初始化） | "all"(默认就是all) | "async"（动态加载）
minSize: 0, // 最小尺寸，默认0 minChunks: 1, // 最小 chunk ，默认1 maxAsyncRequests: 1, // 最大异步请求数， 默认1 maxInitialRequests: 1, // 最大初始化请求书，默认1 name: () => {}, // 名称，此选项课接收 function cacheGroups: { // 缓存组会继承splitChunks的配置，但是test、priorty和reuseExistingChunk只能用于配置缓存组。 priority: "0", // 缓存组优先级,即权重 false | object | vendor: { // key 为entry中定义的 入口名称 chunks: "initial", // 必须三选一： "initial"(初始化) | "all" | "async"(默认就是异步) test: /react|lodash/, // 正则规则验证，如果符合就提取 chunk name: "vendor", // 要缓存的 分隔出来的 chunk 名称 minSize: 0, minChunks: 1, enforce: true, reuseExistingChunk: true // 可设置是否重用已用chunk 不再创建新的chunk } } } } 复制代码SplitChunksPlugin configuration items lot, you can go to the official website to learn how to configure, we now simply list a bit configuration elements.
If we want to extract third-party libraries can be as simple configuration
splitChunks: {
chunks: 'all', // initial、async和all
minSize: 30000, // 形成一个新代码块最小的体积 maxAsyncRequests: 5, // 按需加载时候最大的并行请求数 maxInitialRequests: 3, // 最大初始化请求数 automaticNameDelimiter: '~', // 打包分割符 name: true, cacheGroups: { vendor: { name: "vendor", test: /[\\/]node_modules[\\/]/, //打包第三方库 chunks: "all", priority: 10 // 优先级 }, common: { // 打包其余的的公共代码 minChunks: 2, // 引入两次及以上被打包 name: 'common', // 分离包的名字 chunks: 'all', priority: 5 }, } }, 复制代码This does not seem done, we arranged a big problem?:
- We have to rough packaged with third-party libraries feasible? Of course there is a problem, because a third-party library package, as long as we have a library upgrade or introduce a new library, the chunk will change, then the change of this chunk of will be high, not suitable for long-term cache, another thing, we have to improve the loading speed home, the first priority is to reduce the amount of code to load dependent home, I ask this as react vue reudx basis of the entire application library we have to be home dependent on the outside, like a special library d3.js three.js this particular page to appear is not necessary to load the first screen, so we need to rely on application of basic libraries and special libraries separation.
- When the chunk in a strong buffer period, but the server code has changes how we inform the client? The schematic diagram above we have seen, when the hit resource in cache for the browser cache is read directly without acknowledgment to the server, the server code if this time has been a change, how to do? This time we will not be cached index.html (small anyway html page webpack times to no cache necessary), requires the introduction of script every time the script to update the server, and open hashchunk, its role is when the chunk of change will generate a new hash value, if the same is not subject to change, so that when the index is loaded follow-up script if hashchunk resources has not changed will hit the cache, so if you change the server to re-load the new resource.
The following figure shows how the third-party libraries and specific library Echarts lodash unpacking, base type and the like react with the library of tools split
cacheGroups: {
reactBase: {
name: 'reactBase',
test: (module) => { return /react|redux/.test(module.context); }, chunks: 'initial', priority: 10, }, utilBase: { name: 'utilBase', test: (module) => { return /rxjs|lodash/.test(module.context); }, chunks: 'initial', priority: 9, }, uiBase: { name: 'chartBase', test: (module) => { return /echarts/.test(module.context); }, chunks: 'initial', priority: 8, }, commons: { name: 'common', chunks: 'initial', priority: 2, minChunks: 2, }, } 复制代码We were on the chunk of hash, is shown below, we change chunk2 relevant code, other chunk did not change, only the hash changes chunk2
output: {
filename: mode === 'production' ? '[name].[chunkhash:8].js' : '[name].js',
chunkFilename: mode === 'production' ? '[id].[chunkhash:8].chunk.js' : '[id].js', path: getPath(config.outputPath) } 复制代码
We http cache + webpack hash caching strategy makes full use of the front-end project cache advantage, but webpack The need for the legendary webpack configuration engineer for a reason, because webpack itself is metaphysics, or the above figure as an example, if you chunk2 the relevant code removes a dependency or the introduction of new, but already there is project-dependent, what will happen?
Our normal expectation is that only chunk2 changes, but in fact is a large number of irrelevant chunk of hash changes occurred, which led to our caching strategy fails, the next chart is a hash after the change, we rose with red circle are hash changes, but in fact we only change the chunk2 related code, why is this so?
This is something we need to introduce a plug-in additional HashedModuleIdsPlugin, naming him chunk id with non-self by the way, can solve this problem, although webpack known as 0 configuration, but the common feature is not built-in, to wait until the next version.
webpack hash cache content is recommended to read this article as expand
Author: Looking for 96 sea blue
link: https: //juejin.im/post/5d00820b5188255ee806a1c7
Source: Nuggets
copyright reserved by the authors. Commercial reprint please contact the author authorized, non-commercial reprint please indicate the source.
Reproduced in: https: //www.cnblogs.com/sunshq/p/11051675.html