要讨论Webpack 2中新增的这两个plugin的功能,还要先从使用Webpack打包的项目的前端资源缓存方案说起。
通常在使用了Webpack的项目中我们会使用CommonsChunkPlugin
来将所有依赖的第三方包打包到一个名为vender
的chunk中。与此同时,为了避免每次更改项目代码时导致vender
chunk的chunkHash改变,我们还会单独生成一个manifest
chunk。
举个例子,假设我们有一个项目,项目中入口文件为index.js
。其内容如下:
import add from ‘./src/add‘;
import leftPad from ‘left-pad‘;
import jsonp from ‘jsonp‘;
add(1, 2);
通常我们的webpack.config.js
文件就会有类似如下的配置:
const path = require(‘path‘);
const webpack = require(‘webpack‘);
module.exports = {
entry: {
‘app‘: ‘./index.js‘,
‘vender‘: [‘left-pad‘, ‘jsonp‘]
},
output: {
filename: ‘[name].[chunkHash].js‘,
path: path.resolve(__dirname, ‘build‘)
},
resolve: {
extensions: [‘.js‘]
},
module: {
...
},
plugins:[
new webpack.optimize.CommonsChunkPlugin({
name: [‘vender‘, ‘manifest‘],
minChunks: Infinity,
})
]
};
这时,通过Webpack打包,会生成三个文件:
假设我们修改了./src/add.js
文件,重新打包,会得到:
可以看到只有app
和manifest
这两个chunk的chunkHash改变了,而vender
的chunkHash和之前保持了一致。这就使得vender
可以被缓存在客户端,从而减少客户端的下载量。
但如果是新添加一个文件呢?
假设我们在项目中新加了一个文件./src/add2.js
。此时index.js
的内容如下:
import add from ‘./src/add‘;
import add2 from ‘./src/add2‘;
import leftPad from ‘left-pad‘;
import jsonp from ‘jsonp‘;
add(1, 2);
add2(1);
此时再次构建,会得到如下的输出:
这就和我们期望的行为不一致了,因为我们并没有修改依赖的第三方包,但是vender
chunk的chunkHash也发生了更改。
导致这个结果的原因在于,由于引入了一个新模块,使得打包过程中部分模块的模块ID发生了改变。而模块ID的改变,直接导致了包含这些模块的chunk内容改变,进而导致chunkHash的改变。
注意看下图:
蓝色框中的模块ID为3的模块就是我们新加的模块。由于它被插在了ID为3的位置,导致后续所有模块的ID都发生了更改。
既然找到了问题的原因,那么解决方案也就很明了了。那就是找到一种和顺序无关的模块ID命名方式。最容易想到的就是基于文件名或者文件内容的哈希值这两种方案了。其实也就是今天要说的NamedModulesPlugin与HashedModuleIdsPlugin的功能。
比如,我们在项目中启用HashedModuleIdsPlugin:
plugins:[
new webpack.optimize.CommonsChunkPlugin({
name: [‘vender‘, ‘manifest‘],
minChunks: Infinity,
}),
new webpack.HashedModuleIdsPlugin()
]
此时,再次构建项目得到:
可以看到各个模块的ID已经变成一小段哈希值。这时,在项目中添加./src/add2.js
。重新构建,得到输出:
可以看出,两次构建之间,vender
chunk的chunkhash以及各模块的模块ID都保持了一致。从而达到了最佳的缓存效果。
使用NamedModulesPlugin
效果类似,此处不再演示。本文涉及的所有代码都可以在github上找到。