Skip to content
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

Closed
pksjce opened this issue Sep 7, 2016 · 6 comments
Closed

Document what changes a hash/chunkhash #131

pksjce opened this issue Sep 7, 2016 · 6 comments

Comments

@pksjce
Copy link

pksjce commented Sep 7, 2016

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

@pksjce
Copy link
Author

pksjce commented Sep 7, 2016

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 ?

@pksjce
Copy link
Author

pksjce commented Sep 7, 2016

From @bebraw on October 2, 2015 5:14

This might be related to #1479, #1461, and #1315. There's something going on with hashing unfortunately.

@pksjce
Copy link
Author

pksjce commented Sep 7, 2016

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

@pksjce
Copy link
Author

pksjce commented Sep 7, 2016

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.

@SpaceK33z
Copy link
Member

Note that @jhnns's https://github.com/jhnns/webpack-hash-test will help a lot with documenting this.

hzuhyb pushed a commit to hzuhyb/webpack.js.org that referenced this issue Feb 18, 2017
@skipjack
Copy link
Collaborator

Let's close and merge this discussion with #652.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants