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

Open
dmitry opened this Issue Sep 28, 2015 · 54 comments

Comments

Projects
None yet
@dmitry

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

dmitry commented Oct 9, 2015

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

@dmitry

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

bradrobertson commented Nov 19, 2015

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

LukeLin commented Feb 26, 2016

I have this problem too.

@LukeLin

This comment has been minimized.

LukeLin commented Feb 29, 2016

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

@chilicomputer

This comment has been minimized.

chilicomputer commented Mar 21, 2016

@heldrida

This comment has been minimized.

heldrida commented May 11, 2016

@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

This comment has been minimized.

asjudy commented Jun 15, 2016

I have this problem too.

@pumbers

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

michael8090 commented Sep 28, 2016

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

@dmitry

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

dmitry commented Sep 28, 2016

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

@paramsingh88

This comment has been minimized.

paramsingh88 commented Oct 2, 2016

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

@dmitry

This comment has been minimized.

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

This comment has been minimized.

paramsingh88 commented Oct 3, 2016

Any webpack plugin you can suggest?

@jhnns jhnns closed this Oct 25, 2016

@jhnns

This comment has been minimized.

Member

jhnns commented Oct 25, 2016

See also #90

@michael8090

This comment has been minimized.

michael8090 commented Oct 26, 2016

@jhnns Unfortunately I tried recordsPath and still had different hashes on different machines.

@michael8090

This comment has been minimized.

michael8090 commented Oct 26, 2016

Here is my testing codes, with recordsPath enabled. Anyone having some interest could clone it and run npm install && gulp on different machines to see how the hash differs.

https://github.com/michael8090/test-webpack-hash

@dmitry

This comment has been minimized.

dmitry commented Oct 26, 2016

@jhnns yes, I agree with @michael8090 - it's not related to the ordering of module ids that may change between different builds. I've tried similar aproach with just react module - and it didn't worked well. As I remember, when I removed npm_modules path, hash didn't changed. Hash was changed only when machine was changed.

@jhnns

This comment has been minimized.

Member

jhnns commented Oct 26, 2016

different hashes on different machines.

This is always possible. We can't change that because of the way how npm works.

@dmitry

This comment has been minimized.

dmitry commented Oct 26, 2016

@jhnns any points to push this forward and solve?

@michael8090

This comment has been minimized.

michael8090 commented Oct 27, 2016

@jhnns NPM seems not to be the root cause of the issue. As shown above, the hash changes simply by changing the folder name of the project on the same machine for the same NPM installation, but it's not that easy to be reproduced compared with that on different machines:

It clearly has something to do with the path of the source code. As shown below, 'wtf-webpack', 'wtf-webpack-4' and 'wtf-webpack-5' has 'replace.eddb7ea40a020255062d.js' while 'wtf-webpack-2' has 'replace.73538f954096e7f818b2.js'...

@jhnns

This comment has been minimized.

Member

jhnns commented Oct 27, 2016

I've create a small test repository with a README about my findings: https://github.com/jhnns/webpack-hash-test

I can confirm that hashes change if a filename is changed. This is surprising to me (and probably a bug) because the bundle does not contain any information about filenames anymore. I can also confirm that hashes are different on different OS. This is a logical consequence since Windows uses backslashes as path separator. It's probably also due to the fact that Windows uses CRLF for new lines. There's nothing we can do about it.

Can someone of you checkout my test repository and compare the hashes (and then tell me what OS you're using)?

@jhnns jhnns reopened this Oct 27, 2016

@jhnns

This comment has been minimized.

Member

jhnns commented Oct 27, 2016

However, please keep in mind that there are a lot of potential causes for legitimate hash changes, see also #1315.

@jhnns jhnns changed the title from Different hash on different computers to Hash changes if a filename is changed Oct 27, 2016

@dmitry

This comment has been minimized.

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

This comment has been minimized.

jouni-kantola commented Jan 8, 2017

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

@knowThis

This comment has been minimized.

knowThis 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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

aguynamedben commented Feb 20, 2018

@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

This comment has been minimized.

webpack-bot commented Oct 30, 2018

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

This comment has been minimized.

ogonkov commented Oct 30, 2018

Is it still an issue?

@webpack-bot webpack-bot removed the inactive label Oct 30, 2018

@tenkiller

This comment has been minimized.

tenkiller commented Oct 30, 2018

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.

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