-
-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document what changes a hash/chunkhash #131
Comments
From @virajsanghvi on October 1, 2015 23:38 I got around my problem by adding a part to filenames that I control (e.g. an incrementing counter) that I can use to bust caches. My main problem now, though, is that it looks like the UglifyJS plugin is not determinate in how it minifies the output. In one instance, the chunkhash is the same, and the only difference is that the top closure has different argument names (which then propagates through the file). My guess is the files would be functionally the same, but my problem is this prevents me from being able to validate that the file already exists. Is this a known limitation? Is there a known workaround? Also, side question: is it safe to assume that the plugins are executed in the order they appear here: https://webpack.github.io/docs/plugins.html#the-compilation-instance ? |
From @dmitry on October 2, 2015 14:48 That would be great to document what changes a hash and chunkhash. I've tried to debug, but I found not all the points which are affecting. Main modificators are located here: https://github.com/webpack/webpack/blob/master/lib/Compilation.js#L765 |
From @virajsanghvi on October 13, 2015 1:32 Opened #1510 to deal with UglifyJsPlugin issues. Outside of this, it does seem like any plugin after 'after-hash' will not contribute to the hash/chunkhash, but I'm handling those issues via an incremented cache buster that I plan to use on webpack configuration changes. |
Note that @jhnns's https://github.com/jhnns/webpack-hash-test will help a lot with documenting this. |
fix coffee-redux-loader.md
Let's close and merge this discussion with #652. |
From @virajsanghvi on September 30, 2015 23:5
I've been encountering some weirdness with hashes. They always seem to change with content changes, but not always with loader/plugin changes (e.g. BannerPlugin). This leads to problems when pushing to CDNs. There are many issues that have been opened related to this, but I'm just wondering: what is the expectation for when hashes change? Should any change to the output be reflected in the hash (that ideal) or is there some point in compilation when this is no longer the case? Knowing this might help me figure out a way to mitigate these issues.
Also, is there any way of providing some extra value (e.g. some incremental counter), that when changed, would be used in generation of the hashes? While this would generate new hashes for everything, it is a quick way to ensure that configuration changes (e.g. new loaders/plugins) don't cause conflicts when there is new content.
Copied from original issue: webpack/webpack#1486
The text was updated successfully, but these errors were encountered: