webpack: webpack does not generate always unique chunk hashes

Hello, we have noted that sometimes webpack generates the same hash for a chunk, even if the file content has been changed.

Due to this, changes sometimes are not propagated, we experience an error similar to #959 and we’re forced to clear the cache/CDN to make the things work.

We are using the following plugins in the given order:

ExtractTextPlugin
CommonsChunkPlugin
OccurenceOrderPlugin
WebpackAssetsMapPlugin //custom plugin, writes the json stats file to the disk
DeduplePlugin
UglifyJsPlugin

Let me know if you need further details, V.

About this issue

Original URL
State: closed
Created 9 years ago
Reactions: 5
Comments: 42 (9 by maintainers)

Commits related to this issue

add md5 hash for test: https://github.com/webpack/webpack/issues/1155 — committed to d-band/dool-build by helloyou2012 8 years ago

Most upvoted comments

As @le12484 recommended, I wrote https://www.npmjs.com/package/webpack-plugin-hash-output to precisely fix this problem. It guarantees that you’ll get a [chunkhash] that is always a hash of the content. It solves the two errors in this thread (as summarized by @jhnns).

It even has the option to fail the compilation if, for whatever reason, that postcondition is not met (see option validateOutput).

scinos on Nov 11, 2017

As far as I’m understanding it, we have two issues here:

Some people are complaining about different hashes although the file content is the same @dmitry
Some people are complaining about the same hashes although the file content has changed @dtothefp

Please note that webpack hashes the final result (chunks and assets), which means that loaders and plugins have been executed before. Thus it is possible that you don’t get the same hashes for the same file content, because you might have installed different versions of loaders and plugins (at least when using npm).

Same goes the other way round. For instance, if you’re using tree-shaking, you might get the same hashes for different file contents if unused code is removed.

It would be very helpful if you could reproduce the error without any plugin. @dtothefp maybe it’s an error with the sri-stats-webpack-plugin? Try to remove as much as the possible so that we can locate the error.

jhnns on Oct 21, 2016

@bebraw I just quickly put together this repo https://github.com/dtothefp/webpack-broken-sha. Made a branch where I changed JS slightly and got a different sha so ¯\_(ツ)_/¯.

What we saw in the past is that this happened overtime, some deploys with differing content had the same hash and some had different. The only way we knew is when subresource integrity broke because it got cached content (i.e. a deploy with changed content had the same hash as a previous deploy and the CDN served the previous deploys content).

If anyone wants to play around with the repo above to try and reproduce feel free. It’s just a basic setup with React and CSS modules.

dtothefp on Jan 25, 2017

Switching from [chunkhash] to [contenthash] solved the problem with the same name of the css file with the different content.

new ExtractTextPlugin({ filename: "css/[name].[chunkhash].css" }) vs new ExtractTextPlugin({ filename: "css/[name].[contenthash].css" })

mpotomin on Oct 25, 2017

Anyone using https://github.com/scinos/webpack-plugin-hash-output plugin to work around this problem?

It generate the hash from the final content files.

le12484 on Jul 24, 2017

@jhnns essentially it took months of build up in S3 for this to start happening. I’m using [chunkhash]-[name] for CSS and JS compilation. We also switched from Webpack 1.x to Webpack 2.1.0-beta.22, not sure if that somehow could have allowed an overlapping of file name hashes? I’m using the SRI stats plugin https://github.com/mikechau/sri-stats-webpack-plugin to generate the subresource integrity stats.

Essentially here is the flow that results in failure that took us a while to figure out what was going on:

webpack generates CSS/JS files in CI with the hashed filename
SRI plugin generates stats for sha of the file that can be included on the integrity attribute for a script or link tag
CSS/JS assets get uploaded to S3, if a previous filename exists on S3 it is overwritten by uploaded content
template is generated on server, static template generator, or lambda using the generated hashed filenames and SRI to make the script and link
if there was a filename collision on S3 due to improper hashing by webpack then cached content will potentially be served and this content will NOT match the SRI integrity attribute sha
everything breaks and people get 😢 / 😠

I wish I could reproduce when / how this happens but it seems to start showing up lately across many of our applications through many Travis CI builds that upload static assets to S3. I resorted to using the md5 webpack plugin and seems to be working for now.

dtothefp on Oct 19, 2016

Looks like this isn’t fixed as of webpack@2.1.0-beta.22 and is causing us a lot of problems with subresource integrity because cached contents are getting served that don’t have a matching integrity sha. @bebraw is a plan for a fix in the works for webpack 2?

dtothefp on Oct 18, 2016

@sokra Ping. I am not able to find the fix you’re talking about. I have also tested the thing on my environment and the issue persists.

XVincentX on Sep 8, 2015