-
Notifications
You must be signed in to change notification settings - Fork 12k
Unreliable build hashes when running ng build --aot
and after using ng eject
#8640
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
Comments
I'm sorry but I'm not really sure what we can do about this here. After ejecting you're just running webpack with the given config file. Maybe their stat reporting shows a different hash than ours? Maybe you can get some more information on their issue tracker. |
@filipesilva I may be looking in the wrong spot, but angular-cli seems to be displaying the default hash that webpack provides, which is literally the hash at the root of the stats object (https://github.com/angular/angular-cli/blob/master/packages/@angular/cli/utilities/stats.ts#L31). Regardless of the stats being formatted differently, I don't see why the data would be any different unless webpack has a bug on how they generate their hash, which potentially would show before ejecting as well. Maybe I'm missing something, and I'd be glad to be proven wrong, but I don't see how this would be a webpack issue. To clarify, I think this becomes an angular-cli issue because the config in question is literally the unmodified generated config output by Happy to get some clarification if I'm mistaken, and perhaps I'm misunderstanding what |
@filipesilva actually, now I'm not getting reproducible hashes using the CLI with
|
@filipesilva To follow up on my above comment, I have new findings. Below I ran The findings: Without AOT, the build consistently outputs the same hashes, so this is perhaps an issue with config passed to webpack when
Below are the results when just using
|
ng eject
ng build --aot
and after using ng eject
Ok, this happening on non-ejected problems points to a bigger problem. It's interesting that this happens in AOT, and that it alternates between two hashes. I've seen something similar to this when I was working on our resource loader (https://github.com/angular/angular-cli/blob/master/packages/@ngtools/webpack/src/resource_loader.ts). The resource loader is responsible for creating a child webpack compilation to compile CSS/HTML needed by AOT. I was trying to cache resources by hash when I noticed that hashes for the same resources were not consistent. The same resource could have two different compilation hashes. I looked into for a while but couldn't find out why and was running out of time so I took a different caching approach (I tracked dependencies and did not request a new compilation until they changed). So I have to guess this problem is related. I still don't know why it happens. |
After reading links beyond, I think that it is a webpack problem: |
@Taha-Di-Nero I agree that there are a multitude of reasons, sometimes clearer than others, as to why webpack hashes change. In this instance the issue that has particularly caught my attention is that the compilation hash changes after seemingly nothing else has—not adding a chunk, nothing lazy loading, and no source code changes whatsoever. As mentioned above, if that's a webpack issue I'd be happy to report it there. However, I haven't necessarily faced this issue in other projects outside of my experience with angular-cli, so it's hard for me to report a specific issue I cannot replicate with another config. |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Versions
Repro steps
The following are the exact commands I'm taking to reproduce. The items of note here are the "main" hashes (not the chunk or bundle hashes), which I'm marking with
<=====
to the right of each relevant hash.Observed behavior
After
ng eject
the main hash are not reliably the same, regardless of no change. Interestingly enough, the chunkhashes are the same, but the main hash changes.Desired behavior
Running the build task two times consecutively should render the same results. This may be related to a plugin order issue.
The text was updated successfully, but these errors were encountered: