关于webpack:webpack的chunk生成逻辑

刚接触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的其余文章：

1. webpack的加载