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

Hash changes if a filename is changed #1479

Closed
dmitry opened this issue Sep 28, 2015 · 58 comments
Closed

Hash changes if a filename is changed #1479

dmitry opened this issue Sep 28, 2015 · 58 comments

Comments

@dmitry
Copy link

dmitry commented Sep 28, 2015

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

@dmitry
Copy link
Author

dmitry commented Sep 30, 2015

I can reproduce this issue with following code:

webpack.config.js

var path = require('path');

var ROOT_PATH = path.resolve(__dirname);

module.exports = common = {
  entry: path.resolve(ROOT_PATH, 'app'),
  resolve: {
    extensions: ['', '.js']
  },
  output: {
    path: path.resolve(ROOT_PATH, 'build'),
    filename: 'bundle.js'
  },
  module: {
    loaders: [
      {
        test: /\.js$/,
        loaders: []
      }
    ]
  }
};

index.js

require('react');

@dmitry
Copy link
Author

dmitry commented Oct 8, 2015

Using webpack-md5-hash it was solved for me, but still I would like to see it working out of the box.

@dmitry
Copy link
Author

dmitry commented Oct 9, 2015

Looks like an issue is related to the relative / absolute path in the libraries.

@dmitry
Copy link
Author

dmitry commented Oct 21, 2015

Looks like this one could be related to this one: #1450

@bebraw bebraw added the bug label Nov 14, 2015
@ianwith
Copy link

ianwith commented Nov 19, 2015

Any progress on this issue?
Hash is different on different machines, it's troublesome...Can anyone tell how does webpack generate the [hash]

@bradrobertson
Copy link

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.

@dmitry
Copy link
Author

dmitry commented Nov 19, 2015

@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 require / import inside the node_modules libraries.

@wedgex
Copy link

wedgex commented Feb 18, 2016

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

@LukeLin
Copy link

LukeLin commented Feb 26, 2016

I have this problem too.

@LukeLin
Copy link

LukeLin commented Feb 29, 2016

I found it's caused by requiring CSS files, built by extract-text-webpack-plugin

@chilicomputer
Copy link

#2215

@heldrida
Copy link

@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

@asjudy
Copy link

asjudy commented Jun 15, 2016

I have this problem too.

@pumbers
Copy link

pumbers commented Aug 31, 2016

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.

@dmitry
Copy link
Author

dmitry commented Sep 1, 2016

The problem persists when the libraries are loaded into the scripts through the require. Seems like node_modules absolute path converts differently.

@michael8090
Copy link

Same here. And it breaks the deploy of our prod server... as we deploy frontend files and backend files on different machines.

@dmitry
Copy link
Author

dmitry commented Sep 28, 2016

@michael8090 can you please report webpack and node version, and your paths of deployment on different servers (capistrano or you are using own solution)?

@michael8090
Copy link

michael8090 commented Sep 28, 2016

@dmitry

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 projectA and a projectB cloned from A .

Before using the webpack-md5-hash plugin, the bundle content of A and B are the same, but the chunkhashes are different.

After using the webpack-md5-hash, the bundle content and hashes are the same.

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

@dmitry
Copy link
Author

dmitry commented Sep 28, 2016

@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.
I don't see any solution how to solve it, may be @sokra knows how to?

@dmitry
Copy link
Author

dmitry commented Sep 28, 2016

@michael-ciniawsky have you tried webpack >= 2.0?

@paramsingh88
Copy link

@dmitry I have the same issue, any help?? I'm using webpack 1.13.1

@dmitry
Copy link
Author

dmitry commented Oct 2, 2016

@paramsingh88 there are no solution at the moment. You have to use some webpack plugins or PR with a fix of that issue.

@paramsingh88
Copy link

Any webpack plugin you can suggest?

@dmitry
Copy link
Author

dmitry commented Oct 27, 2016

@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
ubuntu 14.04
node 4.1.0
npm 2.14.3

@jouni-kantola
Copy link

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

@jingxiuman
Copy link

jingxiuman commented Jul 20, 2017

image
image

I have the same problem! I get version number from "package.json" ,write it in output.filename.when i change version number and no change vendor file ,The vendor chunkhash change.

@iamakulov
Copy link

iamakulov commented Nov 2, 2017

webpack 3.8.1 · Node.js 8.8.0 · Windows 10 build 16299.19

Can confirm that renaming a file still causes chunkhash to change:

1

Can confirm that using the WebpackChunkHash plugin doesn’t fix the issue (the plugin was mentioned in #1856 as a possible solution):

2

Can confirm that using the webpack.HashedModuleIdsPlugin() plugin doesn’t fix the issue:

3

Can confirm that using the recordsPath option doesn’t fix the issue:

code_2017-11-02_23-17-29


What’s interesting though is that with webpack.HashedModuleIdsPlugin(), hashes of b.js and c.js are different – despite the files are the same (I was just renaming b.js to c.js and vice versa). Hash of a.js stays the same. Could this be related to the problem?

@aguynamedben
Copy link

aguynamedben commented Feb 13, 2018

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

@dmitry
Copy link
Author

dmitry commented Feb 13, 2018

@aguynamedben have you tried webpack-md5-hash? As I remember it partially solved an issue (don't really remember when it fails to fix).

BTW we had similar server topology: 1 load balancer -> 2 app servers.

@aguynamedben
Copy link

@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. 🙏

@webpack-bot
Copy link
Contributor

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.

@ogonkov
Copy link

ogonkov commented Oct 30, 2018

Is it still an issue?

@tenkiller
Copy link

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.

@webpack-bot
Copy link
Contributor

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.

@webpack-bot
Copy link
Contributor

Issue was closed because of inactivity.

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

@hopperhuang
Copy link

Is the bug fixed ?

@hopperhuang
Copy link

I also have found that the hashes will change with different folders

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