hash
hash是跟整个项目的构建相关,构建生成的文件hash值都是一样的,所以hash计算是跟整个项目的构建相关,同一次构建过程中生成的hash都是一样的,只要项目里有文件更改,整个项目构建的hash值都会更改。
如果出口是hash,那么一旦针对项目中任何一个文件的修改,都会构建整个项目,重新获取hash值,缓存的目的将失效
_
应用场景:
compilation对象代表某个版本的资源对应的编译进程。当使用Webpack的development中间件时,每次检测到项目文件有改动就会创建一个compilation,进而能够针对改动生产全新的编译文件。compilation对象包含当前模块资源、待编译文件、有改动的文件和监听依赖的所有信息。
compilation在项目中任何一个文件改动后就会被重新创建,然后webpack计算新的compilation的hash值,这个hash值便是hash。
hash可以作为版本控制的一环,将其作为编译输出文件夹的名称统一管理,如下:
output: {
filename: '/dest/[hash]/[name].js', //这里只是 hash 的一种应用场景
}
chunkhash
采用hash计算的话,每一次构建后生成的hash值都不一样,即使文件内容压根没有改变。这样子是没办法实现缓存效果,我们需要另一种hash值计算方法,即chunkhash。
chunkhash 和 hash 不一样,它根据不同的入口文件(Entry)进行依赖文件解析、构建对应的chunk,生成对应的 hsah 值。生产环境中把一些公关库和程序入口文件区分开,单独打包构建,接着采用 chunkhash 的方式生成hash值,那么只要我们不改动公共库的代码,就可以保证其hash 值不会受影响。
由于采用chunkhash,所以项目主入口文件main.js及其对应的依赖文件main.css由于被打包在同一个模块,所以共用相同的chunkhash,但是公共库由于是不同的模块,所以有单独的chunkhash。这样子就保证了在线上构建时只要文件内容没有更改就不会重复构建。
entry:{
main: path.join(__dirname,'./main.js'),
vendor: ['vue']
},
output:{
path:path.join(__dirname,'./dist'),
publicPath: '/dist/',
filname: 'bundle.[chunkhash].js'
}
应用场景:
如果使用hash作为编译输出文件的hash指纹的话,如下
output: {
filename: '[name].[hash:8].js',
path: __dirname + '/built'
}
这样带来的问题是,三个js文件任何一个改动都会影响另外两个文件的最终文件名。上线后,另外两个文件的浏览器缓存也全部失效。这肯定不是我们想要的结果。
根据chunkhash的定义知道,chunkhash是根据具体模块文件的内容计算所得的hash值,所以某个文件的改动只会影响它本身的hash指纹,不会影响其他文件。配置webpack的output如下:
output: {
filename: '[name].[chunkhash:8].js',
path: __dirname + '/built'
}
contenthash
contenthash表示由文件内容产生的hash值,内容不同产生的contenthash值也不一样。在项目中,通常做法是把项目中css都抽离出对应的css文件来加以引用。