5 thoughts on “Hash changes if a filename is changed”

  1. 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 includePaths in the style-loader, which ultimately generates different JS output. These paths actually get stripped on uglification, so the resulting JS between 2 builds is the same, however the hashing happens before uglification, so any dead code optimizations that remove these differences don’t affect the final chunkhash.

    I’m unable to get this working with the webpack-md5-hash plugin at all, I still get different hash names on my files for the same JS.

    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.

  2. 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.

  4. 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 [contenthash]. We’re hoping that the Git revision plugin @aguynamedben referred to solves the problem for us.

  5. Issue was closed because of inactivity.

    If you think this is still a valid issue, please file a new issue with additional information.

Comments are closed.