持久缓存

使用webpack构建工程的时候，我们往常会把功能不同的代码打包到不同的包里(如lib,vendor,业务代码)。 而持久缓存的目的就是每一次更新线上代码的时候，尽可能使内容未做更改的模块的名字和之前保持一致。

使用webpack实现持久缓存主要需要解决：

1. webpack runtime代码分离

2. 稳定moduleID

3. 稳定chunkID

基本配置

webpack有提供2种hash命名的方式，

1.    [hash]： 整次build生成一个唯一的hash值，赋给所有生成的文件。

2.    [chunkhash]: 每个文件会根据其内容生成不同的hash值.

显然，为了将文件名和内容相关联，应该使用chunkhash。

webpack配置

业务代码
build结果

这样配置虽然可以实现持久缓存，但是把所有的代码都打到了一起(vendor, 业务代码等)。

Webpack-Runtime

使用CommonsChunkplugin将vendor单独打包：

vendor打包配置
build结果

现在如果我对业务代码进行更改：

更新后的业务代码

按道理vendor已经单独打包，改变业务代码并不应该改变vendor的hash值，然而

新生成的vendor名变了

原因是CommonsChunkplugin把vendor单独打出来的时候，还会将webpack自己生成的一部分runtime代码一起打进vendor. 如下图，runtime里牵扯到chunkid等容易频繁变更的元素，所以当业务代码发生变化的时候，runtime代码也会变。

这个问题也容易解决，再写一层CommonsChunkplugin把runtime代码单独打出来(CommonsChunkplugin会把runtime的代码打到配置指定的最后一个chunk里):

单独打包runtime代码
vendor,业务代码,runtime代码都单独打包

现在再更改业务代码，业务代码和manifest的内容会变，vendor文件的内容不会受影响。

ModuleID

然而还没完，当我们在业务代码里增加一个entry,vendor的hash值又发生了变化。

增加一个entry
增加entry后build结果

造成这个问题的原因是当我们加入一个新entry的时候，会在业务代码里新增一个module，而webpack默认会依次用整数给这些module命名。比如说当只有一个entry的时候，业务代码里定义了module： 0，1，2，3。vendor里定义了module 4，5。增加一个entry后:业务代码里会定义: 0,1,2,3,4。 vendor里定义module 5，6.

一个entry时的vendor代码头部
二个entry时的vendor代码头部

可见，要生成稳定的chunkhash值，首先必须解决moduleID的问题。

NamedModulesPlugin & HashedModuleIdsPlugin

NamedModulesPlugin：使用文件的相对路径作为moduleID

相对路径代替整数

不过也带来2个问题： 

1.用相对路径代替数字，文件变大了

2.相对路径暴露了

HashedModuleIdsPlugin ：主要就是为了解决以上2个问题，它对相对路径进行一个md5的摘要，不仅避免文件过大，也隐藏了路径。

ChunkID

有时候一些模块可能在页面初始化的时候并用不到，可能会在之后的过程中(比如用户点击事件)才会用到，这一类模块可以通过动态import()来引入。

动态引入foo
动态引入后的build结果

可以看到，动态引入的代码会被单独打包到chunks/里的文件里，而且vendor的值再次发生了改变。造成这个的原因是和moduleID类似，webpack默认使用整数作为chunkID，并且异步加载的chunk会先被赋值。 也就是说在没有动态引入之前，vendor的chunkID是0，动态引入之后，vendor文件的chunkID变为了1，所以造成了内容变化。

NamedChunksPlugin：这个插件会用chunk的字符串name代替整数作为chunkID。不过要注意的是，动态生成的chunk并没有名字，所以需要手动给取个名字。

配置