Chunk hash are not consistent on different machines

[chilicomputer]

When requiring shim for using process in browser, chunk hash variants on different machines.
In the module "lib/NodeSourcePlugin", "getPathToModule" method will return an absolute path of node shim. This will cause different results depending on the path where your project exits on different machines. And when webpack injects variable dependencies such as 'require(/path/to/node_modules/process/browser.js)', the expression used to initialize DependenciesBlockVariable is changed, Which makes the hash of chunk changed too !
Is this a bug ? Or feature ? It is so disturbing that same code but gets different hash.

[sokra]

bug, it was solved at different places by using a relative path. Do you want to create a PR?

[lcxfs1991]

can u guys elaborate more on this issue. like giving an example?
hope to know when it would be fixed since it affects the usage of alias.

[ggarek]

Is the bug still actual?

I wanted to make a PR, started with reproducing the bug.
Created a test project, added process shim for browser, built the project. Then moved a copy around, built again. The hash is the same. Did i miss something?

➜  webpack-hash-bug echo "$(cat src/index.js)"
require('./style.css');
const p = require('process');

document.write('hello, me bug?' + p.env);
➜  webpack-hash-bug echo "$(cat webpack.config.js)"
const path = require('path');

module.exports = {
  entry: './src/index',
  output: {
    path: path.join(__dirname, 'public/'),
    filename: 'app.js',
  },
  module: {
    loaders: [
      {
        test: /\.css$/,
        loader: 'style!css',
        include: path.join(__dirname, 'src/'),
      }
    ],
  },
};
➜  webpack-hash-bug webpack
Hash: c15da39bb2ea9d2572df
Version: webpack 1.13.0
Time: 599ms
 Asset     Size  Chunks             Chunk Names
app.js  13.9 kB       0  [emitted]  main
   [0] ./src/index.js 96 bytes {0} [built]
    + 5 hidden modules
➜  webpack-hash-bug cd ../ && mkdir -p __tmp/a/b/c/d && cp -rf webpack-hash-bug __tmp/a/b/c/d && cd $_/webpack-hash-bug && webpack
Hash: c15da39bb2ea9d2572df
Version: webpack 1.13.0
Time: 458ms
 Asset     Size  Chunks             Chunk Names
app.js  13.9 kB       0  [emitted]  main
   [0] ./src/index.js 96 bytes {0} [built]
    + 5 hidden modules

[chrisdavies]

We're running into this issue right now. We're building our prod deploys using capistrano which dumps the source into a timestamped folder. So, the folder name is different on newly provisioned machines than it is on old machines.

@sokra mentioned: "it was solved at different places by using a relative path." How do we use a relative path? I'm going to investigate and get it working, but I figured you might be able to direct me faster.

Thanks!

[sokra]

This is still an issue.

Relevant file is https://github.com/webpack/webpack/blob/master/lib/node/NodeSourcePlugin.js

The generated require calls need to be relative instead of absolute paths. One can use this.state.module.context to make them relative.

[sxcooler]

There is a workaround:
var WebpackMd5Hash = require('webpack-md5-hash');
...
plugins: [
// Hash the files using MD5 so that their names change when the content changes.
new WebpackMd5Hash(),
...

get this from https://github.com/coryhouse/react-slingshot

[dmitry]

@sokra any idea where to look into to fix this issue?

[zcfan]

I wrote a fix in #3272, first time sending a PR to a serious project, please help me improve it if it's not good enough.

[JoJoChilly]

@zcfan I figured out that you made a pr and it was merged, however it is still a bug to me when running in different machines like Windows and Mac, and i found it that in latest version of webpack, i could not see your code, is it because your code gone missing that the bug is still open?

[zcfan]

@JoJoChilly I believe my code is still there, other contributor improved (and moved) it :-) Checkout the history of NodeSourcePlugin.js.

[sokra]

This should be fixed. If you still see this issue file a new issue with a repro case. Please provide an example with raw webpack (not using plugins modifing how hashes are calculated, i. e. webpack-md5-hash).

[thecalvinchan]

@sokra can you link to the PR that fixed this issue? is it fixed on 3.4? I'm on 3.3 and it's still not working

[marnusw]

Using Webpack 3.6 I get different hashes when using CSS modules. When I build with the same config but without the components using CSS modules the hashes match across machines. This could mean a problem remains in the css-loader (or sass-loader etc.) rather than Webpack itself. I'll create a repo where this can easily be reproduced and a new issue, but thought it might be worth mentioning here.

[aguynamedben]

I don't see why this was closed without being explained. @sokra can you explain what you mean with your comment "it was solved at different places by using a relative path. Do you want to create a PR?" I'm open to creating a PR if this issue can be explained a little more.

There is 2.5 years of history at #1479, maybe this was just closed as a duplicate?

[the-teacher]

We met the issue with different chankhash names on different machines. It's a big problem to reproduce it, because we face this issue on a huge amount of files and there is no any obvious way to reproduce it. Sometimes it happens, sometimes does not. looks like webpack-md5-hash is not a silver bullet also because it has its own issues and also looks abandoned.

[the-teacher]

@dmitry @aguynamedben @thecalvinchan @lcxfs1991

Hey guys! I've made an example of this issue. Me and my colleges checked it already on many machines and all of us got different hashes.

My example uses a one of real examples with using expose-loader, but actually expose-loader is not a cause of this issue. It's just a one way of many to reproduce it; But I hope it is already a good test case to start investigation.

Could you guys check it and let me know about your results?

@sokra could we create a ticket for this issue? It's really important because it affects production servers. It's very unpleasant case when a few front-end servers have different chunkhash names and users can't reach them only randomly though a load balancer.

https://github.com/the-blog/WebpackChunkhashIssue

[the-teacher]

I've written an article with results of my investigation. I hope once it will be helpful to someone.

https://medium.com/@the_teacher/webpack-different-assets-hashes-on-different-machines-the-problem-the-solution-ec6383983b99

[alexander-akait]

@the-teacher can you provide link on PRs?

[the-teacher]

@evilebottnawi hey 👋 In my case there is no any issue in WebPack. Some plugins had / still have issues with this should-not-embed-absolute-paths part of the official documentation.

I found some odd cases, bit I'm not sure in a nature of these issues.

The best recipe I have now is:

1. Find an entry point where a problem exists
2. Check a source code of this entry point before hash is being calculated.
3. Find a diff on different OS
4. Define which plugin is a cause of an issue
5. Update / fork + patch a broken plugin following the manual should-not-embed-absolute-paths

2 broken plugins already have PRs to fix issues. Unfortunately no ones wants to merge them. But they worked for me very well.

• script-loader | Fix issue with absolute paths
• expose-loader | Fix: Absolute paths

Probably there are some other broken plugins. But in my project I found just these.

[alexander-akait]

@the-teacher thanks for investigate, i ping authors of commits, let's wait 2-3 days, and do new PR if no reply