刚接触webpack时，应用webpack打包后只会生成一个被称为bundle的文件，在缓缓相熟webpack后，如果同时对于前端优化有肯定的理解，就会尝试将臃肿的bundle拆分成多个小文件并按需加载。
本文心愿通过对webpack的局部配置进行阐明，让读者对相干的操作有肯定理解和把握。以下操作均是在webpack@4环境下的阐明。
webpack中通过配置的optimization.splitChunks来实现这样的成果，该配置也是SplitChunksPlugins插件的配置。
webpack为optimization.splitChunks提供了默认值，让咱们来看看：
// // ** 默认的splitChunks内容 **//{ chunks: 'async', minSize: 30000, maxSize: 0, minChunks: 1, maxAsyncRequests: 5, maxInitialRequests: 3, automaticNameDelimiter: '~', automaticNameMaxLength: 30, name: true, cacheGroups: { vendors: { test: /[\\/]node_modules[\\/]/, priority: -10 }, default: { minChunks: 2, priority: -20, reuseExistingChunk: true } }};让咱们来认真看看其中的配置
chunks
通过配置该项，开发者能够抉择须要进行优化的chunk，被选中的chunk，其中的modules将被剖析，并依照肯定的策略生成新的chunk。
容许all、async、initial、(chunkname) => boolean四种值，具体成果如下：
- initial: 所有的立刻加载的chunk（例如bundle文件）将被查看
- async: 所有提早加载的chunk将被查看
- all: 等价于
initial+async成果，所有的chunk都将被查看 - (chunkname) => boolean: 函数模式能够提供更细粒度的管制
默认状况为async，所以咱们的bundle不会被优化，这里能够尝试批改为initial之后再进行一次编译。
{ chunks: 'initial',}除了生成bundle之外，可能还会有名为vendors~xxx.js的文件。（如果没有生成的话，能够尝试在代码中引入node_modules中的包，再从新编译后查看后果。）
两次编译后果的变动，即chunks从async变为initial后，bundle文件因作为一个立刻加载的chunk而被优化了。
minSize、maxSize
见名知意，minSize和maxSize限定了新生成的chunk的文件的最小/最大尺寸。只有当筹备生成的chunk的最大和最小文件尺寸，只有在这个尺寸内的chunk文件才会被生成，否则代码会放弃原样。
minSize=30000示意chunk最小应该有30000bytes。maxSize=0示意不限度chunk的最大尺寸。如果设置为一个其余的正当值，例如150000，生成的chunk超过了maxSize的状况下，该chunk将被进一步拆分成更小的chunk。
cacheGroups
cacheGroups是splitChunks配置的一个要害配置，其决定了module应该如何合并成一个新的chunk。
{ vendors: { test: /[\\/]node_modules[\\/]/, priority: -10 },}在cacheGroups配置下的每一个对象，都能够认为是一个cacheGroup，例如下面的代码中是key为vendors的对象。
cacheGroup.test
test用于对所有的module进行筛选，筛选过的module将被放入这个cacheGroup所对应的chunk文件中。上例中通过[\\/]node_modules[\\/]对于module的门路进行测试，最终所有的node_modules门路下的模块都将放在vendors这个chunk下，这也是下面生成vendors~xxx.js的起因。
cacheGroup.priority
定义cacheGroup的优先级。因为对于每个module来说，有可能同时匹配了多个cacheGroup的test规定，此时就须要依据优先级来决定须要放到哪个cacheGroup中。
name
name决定了生成的chunk文件的名字。默认为true状况下，生成的名字格局为为cacheGroup名字~chunk1名字~chunk2名字.js，其中chunk1名字和chunk2名字是因为这个cacheGroup中蕴含了这两个chunk相干的代码，如果有更多的chunk的话以此类推。
automaticNameDelimiter
可能有仔细的读者会留神到上一大节中用于连贯chunk名称的~，其实是automaticNameDelimiter这个配置项设置的。开发者能够通过该配置项来设置本人想用的连接符。
automaticNameMaxLength
默认状况下，会限度name大节中的chunk1名字~chunk2名字局部长度，超出了限度状况下将进行截断。
例如：设为3状况下，vendors-chunk1名字~chunk2名字.js将变成vendors~chu~21737d60.js，仅仅保留了长度=3的chu局部。在呈现截断状况下，会在前面补充一段额定的字符，可能是一种防止文件名反复的机制。
minChunks
当和一个cacheGroup相干的chunk数量超过minChunks时，新的chunk文件才能够生成。
例如，在默认配置中：
{ default: { minChunks: 2, priority: -20, reuseExistingChunk: true }}可能有仔细的读者又会问了：当初说的不是splitChunks.minChunks吗，和cacheGroup.minChunks有什么关系呢？
其实在splitChunks下的所有配置，在cacheGroup中都会继承或者笼罩。所以对于key为vendors的cacheGroup来说，其minChunks为1，根本就是不限度，所以node_modules文件夹下的内容都会被放入到vendors这个chunk。
所以咱们晓得，key为default的cacheGroup，其中会放入至多两个chunk所援用的module。如果须要尝试的，能够通过在两个entry所生成的bundle文件中，援用雷同的module，之后再打包，应该就会发现该module被放到了名为default~chunk1名字~chunk2名字这样的文件中。
（至此心愿大家曾经对于chunk的生成逻辑有了大抵的理解。）
一些对于webpack的其余文章：
- webpack的加载