-
-
Notifications
You must be signed in to change notification settings - Fork 8.7k
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
Webpack build's [contenthash] diverges from build to build #17757
Comments
I've been able to replicate this issue (using Do you know whether this is a regression @abirmingham? (I'm planning to test v5.88.2 - the version I'm using for a work project at the moment - next to see whether the same behaviour occurs) |
Yep, this was also replicable using v5.88.2 after three iterations - I haven't tested any earlier versions of |
Hey James, thanks for taking a peek at this. I haven't tested any other versions with the minimal repro, but in my main project I am using |
You're welcome. Issue #17009 sounds potentially related. I notice that the list of entrypoints generated in the webpack config seems deterministic (generated from numbers 0..6) - is there a reason to use that many input files? The contents of each code file seem to be the same. |
@jayaddison good question! While attempting to reproduce the issue, I noticed that projects under a certain size took a lot longer to reproduce the problem, or were unable to reproduce the problem at all. I wanted a short feedback loop, so I continued adding entrypoints until the problem was reliably reproduced in under 10 iterations. The same is true of the TS files in the |
Could you try removing more of the webpack config, JavaScript code in the modules, etc to continue to narrow this down without affecting the repeatability of it? (I will try to do the same soon too, but not sure when I'll get around to it) It'll probably be a slightly annoying process, but I think we should be able to continue to remove items until -- ideally -- there's a removal where we cross some threshold and the problem stops occurring. Then there'll be the equally tricky part of debugging from there to determine why whatever small difference that is causes the problem in the first place. |
Note: I briefly wondered whether |
A few more observations:
|
I've confirmed that this variance is replicable as far back as So far it does seem that the |
Hey @jayaddison - I was able to spend more time on this, and attempted the following changes: 1
2
3
4
5
Here is the commit containing my stopping point, which can be seen in the repro repository on branch
Note that in the final iteration the bug was only reproduced after the 21st build, and in a prior iteration I stopped running builds at 13 builds. So it is certainly possible that the bug would have been reproduced if builds had continued. This is a tricky one. It's unclear to me whether the extra complexity is necessary or is simply helpful in reproducing the issue in a less prohibitive amount of time. Thank you for your time! |
Thanks - yep, more clues. I do have a feeling that the |
This issue had no activity for at least three months. It's subject to automatic issue closing if there is no activity in the next 15 days. |
Bug report
What is the current behavior?
I am noticing that the contenthash on my production builds is not consistent from build to build. A few observations:
new Worker(new URL('...', import.meta.url));
.mode="production"
, but I was unable to do so. I was also unable to reproduce the issue with a significantly less complex source tree. That is not to say that the issue cannot be produced under these conditions, only that 30 rebuilds did not reproduce the issue for me.Since the build is not deterministic, my production builds are not reproducible, and the contenthash breaks caching.
Additionally, in this case it appears that the output is functionally identical, but in another case my webpack configuration had a bug (introduced by me) that created functional differences in the build output. Because an inconsistent contenthash is often produced, the the bug I introduced was harder to detect, as I could not simply diff filenames as a sanity check.
I have created a repository with a minimal reproduction - https://github.com/abirmingham/repro-webpack-issue-17757. In my experience the issue is typically reproduced within 5 builds, but sometimes more are required.
Here is an example diff of an offending file:
What is the expected behavior?
If no build inputs have changed, all filenames and file content should be identical from build to build.
Other relevant information:
webpack version: 5.89.0
Node.js version: 18.18.2
Operating System: Ubuntu 20.04.6 LTS running docker "node:18" image
Additional tools: None
The text was updated successfully, but these errors were encountered: