dist content-hash different on different path

[zhangbobell]

Version

3.0.5

Reproduction link

https://github.com/zhangbobell/vue-cli-content-hash-reproduce

Node and OS info

Node v8.11.2 / yarn 1.10.1 / macOS 10.14 (18A391)

Steps to reproduce

Do the following 4 steps in two machines or in one machine different path, compare the content-hash in dist/js/app.<content-hash>.js, you will find them not the same.

git clone https://github.com/zhangbobell/vue-cli-content-hash-reproduce.git

cd vue-cli-content-hash-reproduce

yarn

NODE_ENV=production yarn build

I've test in two machines, the result shows below:

Result on machine A (app.js content-hash is efe1aa10):

Result on machine B (app.js content-hash is d9410857):

What is expected?

The two content-hash of app.js on two machines will be the same.

What is actually happening?

They are different

---

The following is my Vue-Cli settings:

I have debug this for some hours, but did not have any valuable result. But I'm sure it has something to do with babel-polyfill, since the difference disappears when I choose No with Use Babel alongside TypeScript for auto-detected polyfills? (Y/n) prompt.

It seems that babel-polyfill will inject absolute path into the compiled js, that lead this bug.

I wish someone could help to debug this.

Thanks for providing a awesome tool !

[zhangbobell]

You can just create two vue projects with vue-cli 3.0 in different directory (using the above settings), then both run NODE_ENV=production yarn build, you'll easily find your content-hash of app.js is different.

Besides, when do not use babel alongside, the content hashes of the two app.js will be the same.

[zhangbobell]

ping..., has anyone came up with a solution?

[zhouxinyong]

@zhangbobell this is a problom since update to vue cli3, the same issue with #1728. No one know how to fix it...

[LinusBorg]

This is probably related to some part of the code (ours or a loader or plugin) using absolute paths to require files. Since the hashes are calculated from the source code, if we have

require(/some/absolute/path/to/some.js)`

somewhere in the generated source, the has will be different.

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

[zhangbobell]

@LinusBorg Thanks for your reply. Yes, I'd read the blog before, link from another issue. And I guess it has something to do with babel-polyfill since the hash become identical when I do not choose babel alongside with TypeScript during creation prompt.

And also I'd searched in babel issues, and someone has encounter with it before. But not really same with ours. So.. Just a guess. I could not easily debug it, so I submit this issue.

Could anyone lend some help ?

[zhangbobell]

@zhouxinyong Thanks your discussion, seems really not very easy to locate the problem. Hope someone knows it.

[haoqunjiang]

It's due to this line:

vue-cli/packages/@vue/babel-preset-app/index.js

Line 148 in 2ac64d6

absoluteRuntime: path.dirname(require.resolve('@babel/runtime/package.json'))

I think we need to expose an option here.

[zhangbobell]

@sodatea Maybe this has no impact about the bug ? I just modified this line of code, the content hash did not changed.

[haoqunjiang]

@zhangbobell Explicitly setting absoluteRuntime to false and then rm -rf node_modules/.cache did fix this issue as I tested just now.

[zhangbobell]

@sodatea Oh, sorry, I just rerun without clearing the cache. I've test just now, it's really the same. Thanks very much.

Maybe I could came up with a Pull Request to fix it. 😄 Or expose an option ?

[haoqunjiang]

@zhangbobell
😀Yeah send a PR please.

The best solution is to provide a good default and expose an option for customization.

We use absoluteRuntime to ensure the correct version is used.
It would be great if we can automatically enable this feature by detecting @babel/runtime's version in the root node_modules directory.
If the detection is not doable, then we can enable absoluteRuntime by default and document its usage for users who really need a consistent hash.