webpack中hash与chunkhash区别和需要注意的问题

项目发布时,为了解决缓存,需要进行md5签名,这时候就需要用到 hash 和 chunkhash等。

问题一:hash问题

  • 使用 hash 对js和css进行签名时,每一次hash值都不一样,导致无法利用缓存
  • 原因是因为, hash 字段是根据每次编译compilation的内容计算所得,也可以理解为项目总体文件的hash值,而不是针对每个具体文件的。(所以每一次编译都会有一个新的hash,并不适用)
  • 解决:不用hash,而用 chunkhash (js和css要使用chunkhash), chunkhash 的话每一个js的模块对应的值是不同的(根据js里的不同内容进行生成)

问题二:图片和字体图标的chunkhash问题

  • 前面有提到,hash在js和css中不实用,所以在项目中所有的文件都准备用 chunkhash ,但是又有了新的问题-img和font等资源中,使用 chunkhash 会报错
  • 解决:因为 chunkhash 只适用于js和css,img中是没有这种东西的,仍然需要用到 hash (这个hash有点区别,每一个资源本身有自己的hash)

问题三:chunkhash重复问题

  • 打包时发现,js和js引入的css的 chunkhash 是相同的,导致无法区分css和js的更新,如下
  index2-ddcf83c3b574d7c94a42.css
  index2-ddcf83c3b574d7c94a42.js
  • 原因是因为webpack的编译理念,webpack将css视为js的一部分,所以在计算chunkhash时,会把所有的js代码和css代码混合在一起计算 *解决:css是使用 ExtractTextPlugin 插件引入的,这时候可以使用到这个插件提供的 contenthash ,如下(使用后css就有独立于js外的指纹了),
//提取css文件
new ExtractTextPlugin({
     filename:‘css/[name].[chunkhash:8].css‘  //提取chunkhash8位码
})
  • 需要注意的是,在新版本中,我在webpack3中测试的是,修改css的内容并不会引起js中的 chunkhash 变动(原因估计是webpack内置的算法变为了只计算js chunk),所以css请务必使用 contenthash ,否则修改后无法生成新的签名,而是会覆盖以前的资源

  转:http://blog.csdn.net/sinat_17775997/article/details/61924901

原文地址:https://www.cnblogs.com/heyushuo/p/8543889.html

时间: 2024-08-28 17:10:02

webpack中hash与chunkhash区别和需要注意的问题的相关文章

webpack中hash、chunkhash、contenthash的区别

hash 项目中所有文件共用相同的hash值 chunkhash 项目中相互依赖的文件共用相同的hash值 contenthash 项目中所有文件均有独立的hash值 原文地址:https://www.cnblogs.com/shingstonelly/p/9697261.html

webpack中的hash、chunkhash和contenthash

这三个hash值都是webpack在打包的时候根据内部算法生成的一串字符串,总的来说最大的不同就是其囊括控制的范围大小不同,对应的控制颗粒度不同. hash hash是对webpack整个一次构建而言,在webpack构建中,文件都会带上对应的MD5值,构建生成的文件hash值都是一样的.如果出口是hash,那么一旦针对项目中任何一个文件的修改,都会构建整个项目,重新获取hash值.如果有目的性的缓存就会失败. chunkhash chunkhash的范围可以针对某个模块而言,它会从入口出发,对

Vue-router 中hash模式和history模式的关系

Vue-router 中hash模式和history模式的关系 在vue的路由配置中有mode选项 最直观的区别就是在url中 hash 带了一个很丑的 # 而history是没有#的 mode:"hash"; mode:"history"; hash模式和history模式的不同 对于vue这类渐进式前端开发框架,为了构建 SPA(单页面应用),需要引入前端路由系统,这也就是 Vue-Router 存在的意义.前端路由的核心,就在于 -- 改变视图的同时不会向后端

Webpack中的sourcemap

Webpack中sourcemap的配置 sourcemap是为了解决开发代码与实际运行代码不一致时帮助我们debug到原始开发代码的技术.尤其是如今前端开发中大部分的代码都经过编译,打包等工程化转换.比如开发环境下用scss写样式, 想在浏览器中在线编辑css那样编辑scss就不是那么容易了.从我自己看过的资料中, sourcemap的概念最早出现在12年, jquer1.9是较早支持sourcemap的库.这篇博客比较有代表性:Introduction to JavaScript Sourc

MySQL的btree索引和hash索引的区别

Hash 索引结构的特殊性,其检索效率非常高,索引的检索可以一次定位,不像B-Tree 索引需要从根节点到枝节点,最后才能访问到页节点这样多次的IO访问,所以 Hash 索引的查询效率要远高于 B-Tree 索引. 可能很多人又有疑问了,既然 Hash 索引的效率要比 B-Tree 高很多,为什么大家不都用 Hash 索引而还要使用 B-Tree 索引呢?任何事物都是有两面性的,Hash 索引也一样,虽然 Hash 索引效率高,但是 Hash 索引本身由于其特殊性也带来了很多限制和弊端,主要有以

java中==与equel的区别

转载自:http://xiashengchao.iteye.com/blog/753409 值类型是存储在内存中的堆栈(以后简称栈),而引用类型的变量在栈中仅仅是存储引用类型变量的地址,而其本身则存储在堆中. ==操作比较的是两个变量的值是否相等,对于引用型变量表示的是两个变量在堆中存储的地址是否相同,即栈中的内容是否相同. equals操作表示的两个变量是否是对同一个对象的引用,即堆中的内容是否相同. ==比较的是2个对象的地址,而equals比较的是2个对象的内容. 显然,当equals为t

java中==与equals的区别

值类型是存储在内存中的堆栈(以后简称栈),而引用类型的变量在栈中仅仅是存储引用类型变量的地址,而其本身则存储在堆中. ==操作比较的是两个变量的值是否相等,对于引用型变量表示的是两个变量在堆中存储的地址是否相同,即栈中的内容是否相同. equals操作表示的两个变量是否是对同一个对象的引用,即堆中的内容是否相同. ==比较的是2个对象的地址,而equals比较的是2个对象的内容. 显然,当equals为true时,==不一定为true: 一.String中的equals和== 1. public

java中equals和==的区别 (转)

java中equals和==的区别  值类型是存储在内存中的堆栈(以后简称栈),而引用类型的变量在栈中仅仅是存储引用类型变量的地址,而其本身则存储在堆中. ==操作比较的是两个变量的值是否相等,对于引用型变量表示的是两个变量在堆中存储的地址是否相同,即栈中的内容是否相同. equals操作表示的两个变量是否是对同一个对象的引用,即堆中的内容是否相同.  ==比较的是2个对象的地址,而equals比较的是2个对象的内容. 显然,当equals为true时,==不一定为true: 一.String中

Webpack中的路径

webpack中涉及许多路径参数的配置.在此做个整理. context context是webpack编译时的基础目录,entry入口会相对于此目录查找. 若不配置,默认值是当前目录,webpack设置context.默认值代码: this.set("context", process.cwd()); 即webpack运行所在目录. context应该是绝对路径,假设入口是src/main.js,则可以设置 { context: path.resolve("./src&quo