[英]What is the purpose of webpack [hash] and [chunkhash]?
Could somebody tell me what is the the purpose [hash] and [chunkhash] and where do they come from? 有人可以告诉我,[哈希]和[chunkhash]的目的是什么?它们来自哪里?
output: {
path: "/home/proj/cdn/assets/[hash]",
publicPath: "http://cdn.example.com/assets/[hash]/"
}
This one wasn't obvious for me for a while, so I think it deserves some more detailed explanation. 这个对我来说暂时不明显,所以我认为值得一些更详细的解释。
What the official documentation says: 官方文件说:
A brief description from the official documentation about their purpose: 官方文档中有关其用途的简要说明:
A simple way to ensure the browser picks up changed files is by using
output.filename
substitutions. 确保浏览器选择已更改文件的一种简单方法是使用output.filename
替换。 The[hash]
substitution can be used to include a build-specific hash in the filename, however it's even better to use the[contenthash]
substitution which is the hash of the content of a file, which is different for each asset.[hash]
替换可用于在文件名中包含特定于构建的哈希,但是使用[contenthash]
替换甚至更好,该替换是文件内容的哈希值,对于每个资产而言是不同的。
Another explanation one by one from the documentation of output.filename
: 从output.filename
的文档中逐一解释:
[hash]
is a "unique hash generated for every build" [hash]
是“为每个构建生成的唯一哈希” [chunkhash]
is "based on each chunks' content" [chunkhash]
是“基于每个块的内容” [contenthash]
is "generated for extracted content" [contenthash]
是“为提取的内容生成的” Let's make it more more understandable with examples: 让我们通过例子让它更容易理解:
I have 3 files in my src
directory: index.js
, index.css
, vendors.js
我的src
目录中有3个文件: index.js
, index.css
, vendors.js
Relevant parts from my example Webpack config: 我的示例Webpack配置中的相关部分:
(not a full, working config!) (不是一个完整的,有效的配置!)
entry: {
index: ["./src/index.js", "./src/index.css"],
vendors: ["./src/vendors.js"]
},
output: {
filename: "[name].[hash].js"
}
plugins: [
new MiniCssExtractPlugin({
filename: "[name].[hash].css"
})
]
So I have 2 chunks name, index
and vendors
, but look that the index
chunk will also have css
content because it imports a css
file in the array. 所以我有2个块名称, index
和vendors
,但看看index
块也将有css
内容,因为它导入数组中的css
文件。 When building, the css
part will be exported to a separate file using MiniCssExtractPlugin
(in my case) but Webpack knows that index.js
and index.css
belong to the same chunk. 在构建时, css
部分将使用MiniCssExtractPlugin
(在我的例子中)导出到单独的文件中,但Webpack知道index.js
和index.css
属于同一个块。
Now let's try to build it with different hashing types. 现在让我们尝试用不同的散列类型构建它。 (changing the two filename
option equally) (平均更改两个filename
选项)
Using [hash]: 使用[hash]:
Every file has the same hash, because [hash]
is generated based on all of our used source files. 每个文件都具有相同的哈希值,因为[hash]
是基于我们使用的所有源文件生成的。 If I re-run the build without changing anything, the generated hash will remain the same. 如果我在不更改任何内容的情况下重新运行构建,则生成的哈希将保持不变。 If I edit only one file then hash will change and all my generated bundles will have this new hash in their name. 如果我只编辑一个文件,那么哈希将会改变,我生成的所有包将在其名称中包含这个新哈希。
Using [chunkhash]: 使用[chunkhash]:
As you see, the 1st and 2nd files were coming from the same index
chunk, so they have the same hash in their name. 如您所见,第一个和第二个文件来自同一个index
块,因此它们的名称中包含相同的哈希值。 It's because [chunkhash]
is generated based on the whole content of the given chunk. 这是因为[chunkhash]
是基于给定块的整个内容生成的。 So if I edit let's say index.css
and re-build, the files coming from the index
chunk will have a new hash, but the one from vendors
chunk will remain the same as was before. 因此,如果我编辑让我们说index.css
并重新构建,来自index
块的文件将有一个新的哈希,但来自vendors
块的文件将保持与以前相同。
Using [contenthash]: 使用[contenthash]:
This one is obvious. 这一点很明显。 Each generated file has got a unique hash in their name, calculated from the content of that file. 每个生成的文件在其名称中都有一个唯一的哈希值,根据该文件的内容计算得出。 If I change let's say index.css
an re-build, only the generated index.css
will have a new hash. 如果我改变让我们说index.css
重新构建,只有生成的index.css
会有一个新的哈希。
Basically its related to browser cacheing - when you serve assets you generally want to tell the client/browser that they can use the same script/stylesheet/jpeg etc without having to download it every single time. 基本上它与浏览器缓存有关 - 当你提供资源时,你通常想告诉客户端/浏览器他们可以使用相同的脚本/样式表/ jpeg等,而不必每次都下载它。 This is done by sending the appropriate HTTP header fields. 这是通过发送适当的HTTP头字段来完成的。
The problem then is how long should you tell the client they can keep using the same stylesheet for example? 那么问题是你应该多长时间告诉客户他们可以继续使用相同的样式表? If you redesign your site and they dont download your new stylesheet they wont see those changes. 如果你重新设计你的网站,他们不下载你的新样式表,他们不会看到这些变化。 The solution is usually to add some kind of identifier or version number to the stylesheet file name - if this id/version changes when the stylesheet changes (and thus the file name is different) the browser will download it again (this is known as cache busting). 解决方案通常是在样式表文件名中添加某种标识符或版本号 - 如果样式表更改时此id /版本发生更改(因此文件名不同),浏览器将再次下载它(这称为缓存破坏)。
Basically webpack can add a hash to the bundle output name that, being a function of the bundle content, will be different when the content changes - thus automating the process. 基本上,webpack可以向bundle输出名称添加一个哈希值,它作为bundle内容的一个函数,在内容发生变化时会有所不同 - 从而使进程自动化。 chunkhash
does the same thing if you are splitting a bundle into multiple chunks. 如果chunkhash
一个包拆分成多个块, chunkhash
做同样的事情。
Heres some non-webpack related discussion: Strategies for Cache-Busting CSS 下面是一些非webpack相关的讨论: Cache-Busting CSS的策略
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.