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

rebuild from cache changes contenthash #454

Open
dreyks opened this issue Sep 29, 2018 · 2 comments · May be fixed by #458
Open

rebuild from cache changes contenthash #454

dreyks opened this issue Sep 29, 2018 · 2 comments · May be fixed by #458

Comments

@dreyks
Copy link

dreyks commented Sep 29, 2018

reproduction repo https://github.com/dreyks/hswp_fail/tree/contenthash

Expected Behavior

Rebuilding unchanged code from cache should result in exact same file and filename

Actual Behavior

Files are same but filenames containing [contenthash] are different.

Steps to Reproduce

https://github.com/dreyks/hswp_fail/tree/contenthash

  1. run yarn webpack - output: main-2f138c469b6d1cc42329.js 3.8 KiB 0 [emitted] main
  2. run yarn webpack again - output: main-80bb0d27ee34d918376b.js 3.8 KiB 0 [emitted] main

Additional info

  • this only happens in 'production' mode
  • [chunkhash] has the same issue
  • I've tried changing webpack versions and figured out that when running with webpack@4.6.0 does not produce this issue
@dreyks
Copy link
Author

dreyks commented Sep 30, 2018

ok i think i'm getting closer

when HS freezes modules it calls _initBuildHash which recalculates the module hash even if it was already calculated before.
moreover at this stage module.buildMeta is changed since module hash was calculated now containing providedExports key, (i think webpack adds this information only in production build) so the recalculated hash is different from original. and when such module is read back from cache on the next run it has a new module hash which affects contenthash of the whole chunk

possible solution would be to check if module._buildHash is present and not call _initBuildHash if that is the case. or modify the _initBuildHash itself not to recalculate the hash but that's on webpack

my current workaround is a monkeypatch

const NormalModule = require('webpack/lib/NormalModule')
const original = NormalModule.prototype._initBuildHash
NormalModule.prototype._initBuildHash = (compilation) => {
  if (this._buildHash !== '')
    return
  original(compilation)
}

@dreyks dreyks linked a pull request Oct 3, 2018 that will close this issue
@catskull
Copy link

I think I'm also running into this. For me, I build and it generates the cache. Then I build again, and it builds from cache. Then I build again, and it says the last cache didn't finish saving.

sebjacobs pushed a commit to futurelearn/webpack-config that referenced this issue Jul 12, 2019
We have recently noticed some inconsistent asset hashes between
different boxes in production. We believe that this is the result of a
caching issue with the `hard-source-webpack-plugin`[1].

The safest thing to do for the time being is to temporarily remove the
plugin whilst we investigate further. This means that our deployment
times will take a hit (~5 mins to build webpack assets) but that feels
better than not being able to deploy safely :-)

[1] mzgoddard/hard-source-webpack-plugin#454
thomasmarshall pushed a commit to futurelearn/webpack-config that referenced this issue Oct 25, 2019
We have recently noticed some inconsistent asset hashes between
different boxes in production. We believe that this is the result of a
caching issue with the `hard-source-webpack-plugin`[1].

The safest thing to do for the time being is to temporarily remove the
plugin whilst we investigate further. This means that our deployment
times will take a hit (~5 mins to build webpack assets) but that feels
better than not being able to deploy safely :-)

[1] mzgoddard/hard-source-webpack-plugin#454
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants