初衷
webpack4出了两个月，发现大家包括我对splitchunk的使用都还是在摸索阶段。我也看了挺多别人的配置demo，都觉得不太满意或者没得到太好的解惑，issue 下面的问题也没什么人回复，只能自己操作了，顺便记录下来，如果大家有更好的，欢迎评论区留下地址。
常用参数
如果你对这些配置还是不熟悉的话，一拉到底，看看文档
正文
先总览一下所有配置，后续会根据demo跑一遍常见的需求。
我要评论
optimization: {
splitchunks: {
chunks: "async", // 必须三选一： "initial" | "all"(推荐) | "async" (默认就是async)
minsize: 30000, // 最小尺寸，30000
minchunks: 1, // 最小 chunk ，默认1
maxasyncrequests: 5, // 最大异步请求数， 默认5
maxinitialrequests : 3, // 最大初始化请求书，默认3
automaticnamedelimiter: '~',// 打包分隔符
name: function(){}, // 打包后的名称，此选项可接收 function
cachegroups:{ // 这里开始设置缓存的 chunks
priority: 0, // 缓存组优先级
vendor: { // key 为entry中定义的 入口名称
chunks: "initial", // 必须三选一： "initial" | "all" | "async"(默认就是async)
test: /react|lodash/, // 正则规则验证，如果符合就提取 chunk
name: "vendor", // 要缓存的 分隔出来的 chunk 名称
minsize: 30000,
minchunks: 1,
enforce: true,
maxasyncrequests: 5, // 最大异步请求数， 默认1
maxinitialrequests : 3, // 最大初始化请求书，默认1
reuseexistingchunk: true // 可设置是否重用该chunk
}
}
}
},
接下来看看第一个例子
entry: {
pagea: "./pagea", // 引用utility1.js utility2.js
pageb: "./pageb", // 引用utility2.js utility3.js
pagec: "./pagec" // 引用utility2.js utility3.js
},
optimization: {
splitchunks: {
cachegroups: {
commons: {
chunks: "initial",
minchunks: 2,
maxinitialrequests: 5, // the default limit is too small to showcase the effect
minsize: 0 // this is example is too small to create commons chunks
}
}
}
},
结果如图，一切都很正常 commons~pagea~pageb~pagec.js 文件就是utility2.js commons~pageb~pagec.js，根据上述代码，这里的utility2被引用了三次，首先就被抽离了commons~pagea~pageb~pagec.js，然后utility3被引用了两次就放到了commons~pageb~pagec.js，最后只剩下被引用一次的utility1.js,就直接放到了pagea.js里面，如果这里的utility1.js的也是两次，他还是会新建一个chunk放进去，而不是合并到commons~pageb~pagec.js,除非同入口引用才会合并。
mpagea.js pageb.js pagec.js
这里有个地方是需要优化一下的，就是pagea.js pageb.js pagec.js的代码不多，但是打出来的包很大，肯定是一些webpack的运行文件，直接加上runtimechunk
runtimechunk: "single"
// 等价于
runtimechunk: {
name: "manifest"
}
现在就好了
引用第三方模块 pagea引用vue.js pageb引用react react-dom
vendor: {
test: /node_modules/,
chunks: "initial",
name: "vendor",
priority: 10,
enforce: true
}
但是，这样子的话，会把pagea pageb pagec所有的库都打包到一起vendor.js
假如我想拆分这个vendor.js为pagea-vendor.js pageb-vendor.js怎么办，我试了很久，试出一个最简单的办法,去掉手动的vendor，让插件自动处理。
splitchunks: {
chunks: "all",
cachegroups: {
commons: {
chunks: "initial",
minchunks: 2,
maxinitialrequests: 5, // the default limit is too small to showcase the effect
minsize: 0 // this is example is too small to create commons chunks
}
}
},
后来，我把webpack mode改成production后，发现不管用了，同样的配置，在生产模式下，打包出来的东西有点匪夷所思，vendor-pageb.js被合并到了pageb.js里面了。
后来我折腾了好久也分析不出来为什么，自己折腾出来一种方式，还是老子手动来吧，自动化一边去
commons: {
chunks: "initial",
minchunks: 2,
maxinitialrequests: 5, // the default limit is too small to showcase the effect
minsize: 0 // this is example is too small to create commons chunks
},
'vendor-pagea': {
test: /vue/, // 直接使用 test 来做路径匹配
chunks: "initial",
name: "vendor-pagea",
enforce: true,
},
'vendor-pageb': {
test: /react/, // 直接使用 test 来做路径匹配
chunks: "initial",
name: "vendor-pageb",
enforce: true,
},
成功打包出来了自己想要的东西。
动态引入
动态引入大家应该都不陌生，就是大家所说的懒加载,直接在pagea和pageb页面里动态引入common-async.js，在这里我先说说，splitchunk应该是可以自动化处理类似commonchunk里的async，child等情况的。
import(/* webpackchunkname: "common-async.js" */"./common-async").then(common => {
console.log(common);
})
还不错，成功打包出来了
这时候再试试，在这个common-async.js里面在引入共同的代码f.js，看看会不会重复打包
f.js成功的被抽离出来了，其他文件也没有被重复打包，挺好的。
注意的地方
上面的例子里面配置了一个commons，这里的name可以自己设置，也可以不设置，我是没设置的，你可以试试设置了是什么样子的，然后你就会明白这个name其实在某些情况下还是不设置的比较好。
commons: {
chunks: "initial",
minchunks: 2,
maxinitialrequests: 5, // the default limit is too small to showcase the effect
minsize: 0 ,
name: "commons"
},
源码
参考文章
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持移动技术网。
如对本文有疑问， 点击进行留言回复！！
offset、client、scroll (width,height、left,top、X,Y)
网友评论