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
Hash changes if a filename is changed #1479
Comments
I can reproduce this issue with following code: webpack.config.js
index.js
|
Using |
Looks like an issue is related to the relative / absolute path in the libraries. |
Looks like this one could be related to this one: #1450 |
Any progress on this issue? |
I also have this problem and have spent hours trying to figure out the problem. See here. What I can tell is it's not machine specific per se as I can reproduce it locally by moving my project into 2 different folders. Effectively, my issue is that we're adding in absolute paths to I'm unable to get this working with the Furthermore if you use the CommonChunks plugin, webpack seems to reference chunks using these chunkhashes, so the actual common.js file generated is different for the 2 builds, even though the actual entries themselves are the same. This feels like a fundamental issue with the way webpack generates its hashes. They're somehow generated high up in the compilation chain, based on the JS generated after modules are bundled up, which may or may not (depending on loaders etc) include path specific information. This, thus can make the actual JS output different, which obviously generates a different chunkhash. I'm pretty much out of ideas at this point, it just seems like a failing in the underlying compilation mechanism. I don't think its a stretch to expect consistent hashing of files no matter where the files are compiled. |
@bradrobertson I've found the same root, read more about it here: #1155 (comment); TL;DR I found it's related to the absolute paths that are generated during |
Has any progress been made or work arounds found for this? We've brought in the webpack-md5-hash plugin but are still having one chunk change chunkhash when built on a different machine (or just different directory). |
I have this problem too. |
I found it's caused by requiring CSS files, built by extract-text-webpack-plugin |
@LukeLin can you provide more information; how is it caused by requiring css files ? Can you show some examples ? I'm having the same issue that is reported here, the image hash are different, on different machines; The SVG was quite persistent, but adding a query parameter helps regenerate the correct hash filnema.svg?somestring |
I have this problem too. |
Same here - I'm on 1.12.9. Hash appears consistent between different Windows 7 workstations, but when built on a Red Hat box under Jenkins we get a different hash. We're not loading CSS either, and webpack-md5-hash shows the same problem. |
The problem persists when the libraries are loaded into the scripts through the require. Seems like node_modules absolute path converts differently. |
Same here. And it breaks the deploy of our prod server... as we deploy frontend files and backend files on different machines. |
@michael8090 can you please report webpack and node version, and your paths of deployment on different servers (capistrano or you are using own solution)? |
I've two machines for development, one is a mbp and the other is a pc. mbp: node@6.2.2, webpack@1.13.2 pc: node@6.7.1, webpack@1.13.2 On mac I have Before using the After using the But the content and hashes on my mac are different from the build on my PC, no matter if I use the plugin or not....... |
@michael8090 as I remember, in my case it was an issue when I required react library, or any other lib from the node_modules. When there are no requirements for the node_modules, it worked without issues. I believe once you require, webpack takes absolute path and somehow it changes whole code, so the chunkhash is different. |
@michael-ciniawsky have you tried webpack >= 2.0? |
@dmitry I have the same issue, any help?? I'm using webpack 1.13.1 |
@paramsingh88 there are no solution at the moment. You have to use some webpack plugins or PR with a fix of that issue. |
Any webpack plugin you can suggest? |
@jhnns thanks for digging deeper. Here is my changes https://github.com/dmitry/webpack-hash-test, when hashes DO change if the path outside webpack's context change. webpack 1.13.3 |
Thank you for sharing your findings, @dmitry. This has always puzzled me as well, and remains the same with Webpack 2. As I go back and forth from Windows, MacOS and CI, I see quite a lot of hash changes. This issue explained quite a lot. As I see it, CI is pretty much a requirement for running Webpack. Local push is too fragile, since people will most definitely have different setups. This issue is related: #1856 |
webpack 3.8.1 · Node.js 8.8.0 · Windows 10 build 16299.19 Can confirm that renaming a file still causes Can confirm that using the Can confirm that using the Can confirm that using the What’s interesting though is that with |
This just ruined our Webpack deploy in the 11th hour after 2 weeks of work migrating to Webpack. We had to roll back to figure out what to do. We have 2 webservers behind a load balancer. ~50% of the time, the webserver would request a Webpack-produced file and the request would be routed to the other webserver, resulting in a very confusing situation where some assets loaded and some didn't. It took an hour of wonky partial outage to understand the cause. FWIW we're using djang-webpack-loader, webpack-bundle-tracker, and WhiteNoise to serve Webpack assets. This was very surprising and there aren't really any solutions offered aside from "invest in your CI + deployment bundling a bunch more" or "track bundles in git and dirty up your repo". |
@aguynamedben have you tried BTW we had similar server topology: 1 load balancer -> 2 app servers. |
@dmitry I tried that but was still having issues. I ended up using https://github.com/pirelenito/git-revision-webpack-plugin to use the sha1 from the latest commit. It works for now, but issue this was very surprising and concerning behavior after I had built a lot of trust. The idea of hashing (I think) is to reliably be able to determine if the contents of the files are identical (i.e. for CDN usage). Implementation details in dependency management impacting the hashes is a bug in my book. I'm glad this ticket is still open. 🙏 |
This issue had no activity for at least half a year. It's subject to automatic issue closing if there is no activity in the next 15 days. |
Is it still an issue? |
Yes, this is still an issue. The same problem is happening for our team. We deploy the same web application across multiple UI servers, and the assets built on one of them is named differently from the others for some unknown reason, even when using |
This issue had no activity for at least half a year. It's subject to automatic issue closing if there is no activity in the next 15 days. |
Issue was closed because of inactivity. If you think this is still a valid issue, please file a new issue with additional information. |
Is the bug fixed ? |
I also have found that the hashes will change with different folders |
Hash is differently generated on different computers.
I've tried without image optimizations and source map.
More details on this issue:
erikras/react-redux-universal-hot-example#251
The text was updated successfully, but these errors were encountered: