Angular-cli: ng build --prod is not creating unique hashes

[JohnGalt1717]

Versions

`Angular CLI: 6.0.0
Node: 8.10.0
OS: win32 x64
Angular: 6.0.0
... animations, cli, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router

Package Version

@angular-devkit/architect 0.6.0
@angular-devkit/build-angular 0.6.0
@angular-devkit/build-optimizer 0.6.0
@angular-devkit/core 0.6.0
@angular-devkit/schematics 0.6.0
@ngtools/webpack 6.0.0
@schematics/angular 0.6.0
@schematics/update 0.6.0
rxjs 6.1.0
typescript 2.7.2
webpack 4.6.0`

Repro steps

1. Create a site with ng new
2. Add a lazy path with loadChildren
3. ng build --prod

Observed behavior

Every time production build happens the hashes in the chunks do not change.

Desired behavior

Every single --prod build should result in unique hashes for cache busting.

Mention any other details that might be useful (optional)

Not sure if this is an issue with Angular cli or with webpack but it's definitely effecting Angular. I believe it's also in 5.2.10.

Not sure if this is windows only, but it happens locally on Windows and in VSTS hosted build.

[filipesilva]

I think you're having some weird errors and can't debug it, and so, understandably, you're frustrated. But this is a tracker for bugs and feature requests. If we can we also try to help with support requests. We're very lucky to have awesome community members that also spend time trying to help people here in the issue tracker.

But we can't really help much at all if you don't fill in the issue template. I read your issue and have no idea what's going wrong and how to help you. And when other users search the issue tracker and see your issue, it also doesn't help them.

So I think the best thing to do is to close this issue, and ask you to open a new one. In that new one please fill in the issue template and give us an idea of what's happening and how to reproduce it. That way we'll have a chance to help you.

[JohnGalt1717]

What part of the issue template isn't filled in?

The repro steps?

ng new project name
Add a lazy loaded route
ng build --prod
wait for it to finish
ng build --prod
wait for it to finish.

Observe that the hashes are IDENTICAL. They shouldn't be. Every time prod code is built every chunk should have unique hashes in the file name for cache busting per the documentation.

Didn't think I need to state the obvious with an issue of angular-cli or webpack not creating new hashes on production build, it's self-explanatory.

[JohnGalt1717]

And for the record I did fill in the entire template, but the output of ng --version that it instructs to copy and paste borks GitHub markdown. I've cleaned it up.

[filipesilva]

Thank you for cleaning up the output and clarifying the information.

We change the hashes per bundle content, not per build. So between two builds, if the content of the bundle did not change, the hash will not change.

[JohnGalt1717]

Ok, well it definitely isn't working right because I can make changes and it still isn't updating the hashes. We're getting constant complaints from people about bugs we've already fixed and telling them to clear their cache is fixing it. I have yet to see even one file change it's hash build to build event with changes.

[filipesilva]

Ok that is odd, we test for that in https://github.com/angular/devkit/blob/master/packages/angular_devkit/build_angular/test/browser/output-hashing_spec_large.ts.

I did a simple test right now by adding console.log('hello') to main.ts and I do see the hash changing:

kamik@RED-X1C6 MINGW64 /d/sandbox/latest-project (master)
$ ng build --prod

Date: 2018-05-04T19:37:41.519Z
Hash: f25fd6788a4969c52b70
Time: 13076ms
chunk {0} runtime.6afe30102d8fe7337431.js (runtime) 1.05 kB [entry] [rendered]
chunk {1} styles.34c57ab7888ec1573f9c.css (styles) 0 bytes [initial] [rendered]
chunk {2} polyfills.6c08419970f9e4781b69.js (polyfills) 59.4 kB [initial] [rendered]
chunk {3} main.5c2aab6a636f72a9a865.js (main) 153 kB [initial] [rendered]

kamik@RED-X1C6 MINGW64 /d/sandbox/latest-project (master)
$ ng build --prod

Date: 2018-05-04T19:38:07.685Z
Hash: 41d53ef1d6943f2cd0e2
Time: 9482ms
chunk {0} runtime.6afe30102d8fe7337431.js (runtime) 1.05 kB [entry] [rendered]
chunk {1} styles.34c57ab7888ec1573f9c.css (styles) 0 bytes [initial] [rendered]
chunk {2} polyfills.6c08419970f9e4781b69.js (polyfills) 59.4 kB [initial] [rendered]
chunk {3} main.2f847dc2015268319a27.js (main) 153 kB [initial] [rendered]

You example mentions adding a lazy route though. Can you be more specific? I don't know how you're adding it, and small differences in how you do it can have different behaviours.

Can you make a simple repro where you see this happening and upload it to github? Ideally I would be able to clone it, checkout a commit, ng build --prod, then checkout the another commit with changes, ng build --prod and see no hash change.

[JohnGalt1717]

Here's our base routemodule:

    RouterModule.forRoot([
        { path: 'free30daytrial', component: TrialComponent },
        { path: 'downloads', loadChildren: './downloads/downloads.module#DownloadsModule' },
        { path: 'contact', loadChildren: './contact/contact.module#ContactModule' },
        { path: 'legal', loadChildren: './legal/legal.module#LegalModule' },
        { path: 'product', loadChildren: './product/product.module#ProductModule' },
        { path: 'lesson', loadChildren: './lesson/lesson.module#LessonModule' },
        { path: 'search', loadChildren: './search/search.module#SearchModule' },
        { path: 'account', loadChildren: './account/account.module#AccountModule' },
        { path: 'user', loadChildren: './user/user.module#UserModule', canActivate: [CanActivateUserGuard] },
        { path: 'organization', loadChildren: './organization/organization.module#OrganizationModule', canActivate: [CanActivateOrganizationGuard] },
        { path: 'custom', loadChildren: './custom/custom.module#CustomContentModule', canActivate: [CanActivateOrganizationContentCreatorGuard] },
        { path: 'partner', loadChildren: './partner/partner.module#PartnerModule', canActivate: [CanActivatePartnerSalesGuard] },
        { path: 'markets', loadChildren: './markets/markets.module#MarketsModule' },
        { path: 'reports', loadChildren: './reports/reports.module#ReportsModule', canActivate: [CanActivateOrganizationGuard] },
        { path: 'assessments', loadChildren: './assessments/assessments.module#AssessmentsModule' },
        { path: 'support', loadChildren: './support/support.module#SupportModule' },
        { path: 'about', loadChildren: './about/about.module#AboutModule' },
        { path: 'projects', loadChildren: './projects/projects.module#ProjectsModule', canActivate: [CanActivateProjectGuard] },
        { path: 'expert', loadChildren: './expert/expert.module#ExpertModule' },
        { path: '', pathMatch: 'full', loadChildren: './home/home.module#HomeModule' }
        //{ path: '**', redirectTo: '' }
    ])

Each module also has sub routes that are lazy loaded.

These generate chunks. No matter what chunk you change I get the same hash.

While I have seen it sometimes on my local computer, build to build change this way, on VSTS hosted build servers which blow away everything you just did every session and thus don't have cache, I get exactly the same hashes always (15 builds today, no difference to 31 chunks even though 6 chunks have changed from check-ins today)

[JohnGalt1717]

This is still an issue with 6.0.1

[filipesilva]

I'm not sure what's happening on your VSTS build server and personally don't have one to investigate myself. Without being able to reproduce myself there just isn't much I can do.

On your local machine though, you say it changes so it does sound like it's related to the build server environment. If you can get me a reproduction that I can run on my machine and see this I am happy to investigate, but without one there isn't much hope of fixing the problem.

I can say that we don't do anything special with hashes though. If you can't provide me with a reproduction that doesn't need a specific server, maybe you can try to setup a simple reproduction with just webpack and see if the problem manifests on your server as well, then submit an issue on the webpack repo.

[JohnGalt1717]

VSTS clears EVERYTHING between every build because the build server is a shared resource.

So you should be able to test this by simply whipping everything including all caches for angular/webpack every single time you do a build. It appears that it restarts whatever randomizer is being used and it starts at the first number again resulting in identical hashes.

[davitPetrosyanT]

I am using Angular 5.2 with angular/cli 1.7.4 and also facing the same issue, for example I have lazy loaded module where I am providing service and using some value from service in html, even after I am updating that services ts file prod build does not change the chunks hash, and as a result we are having caching issues

[simmash]

I have facing the same issue since the hash do not change the browser does not load the changes in the page as it continues using cached version.
Angular CLI: 1.7.4
Node: 8.11.3
Angular: 5.2.7

[ghost]

I am facing the same issue. I was using Angular 5.2 and everythin was working fine. I decided to migrate to Angular 6, and since then, there is no more hashing.

λ ng build --prod

Date: 2018-07-02T08:24:52.920Z Hash: a40248a7d88c0fe78c84 Time: 25715ms chunk {app-components-administration-administration-module} app-components-administration-administration-module.js, app-components-administration-administration-module.js.map (app-components-administration-administration-module) 212 kB [rendered] chunk {app-components-exploitation-controle-commande-controle-commande-module} app-components-exploitation-controle-commande-controle-commande-module.js, app-components-exploitation-controle-commande-controle-commande-module.js.map (app-components-exploitation-controle-commande-controle-commande-module) 475 kB [rendered] chunk {app-components-exploitation-exploitation-module} app-components-exploitation-exploitation-module.js, app-components-exploitation-exploitation-module.js.map (app-components-exploitation-exploitation-module) 466 kB [rendered] chunk {app-components-exploitation-source-post-source-post-module} app-components-exploitation-source-post-source-post-module.js, app-components-exploitation-source-post-source-post-module.js.map (app-components-exploitation-source-post-source-post-module) 637 kB [rendered] chunk {main} main.js, main.js.map (main) 532 kB [initial] [rendered] chunk {polyfills} polyfills.js, polyfills.js.map (polyfills) 261 kB [initial] [rendered] chunk {runtime} runtime.js, runtime.js.map (runtime) 8.44 kB [entry] [rendered] chunk {scripts} scripts.js, scripts.js.map (scripts) 577 kB [rendered] chunk {styles} styles.js, styles.js.map (styles) 288 kB [initial] [rendered] chunk {vendor} vendor.js, vendor.js.map (vendor) 7.19 MB [initial] [rendered]
Angular CLI: 6.0.8 Node: 8.11.3 OS: win32 x64 Angular: 6.0.6

I don't know if this is about lazy loading, but my modules are lazy loaded too.

[clydin]

@trichetriche Please ensure that the project's production configuration is configured appropriately. A new project will contain the following:

          "configurations": {
            "production": {
              "fileReplacements": [
                {
                  "replace": "src/environments/environment.ts",
                  "with": "src/environments/environment.prod.ts"
                }
              ],
              "optimization": true,
              "outputHashing": "all",
              "sourceMap": false,
              "extractCss": true,
              "namedChunks": false,
              "aot": true,
              "extractLicenses": true,
              "vendorChunk": false,
              "buildOptimizer": true
            }
          }

[ghost]

What a dumbf... I am, thank you for that information @clydin !

(I'll keep my comment up there, I probably won't be the only one looking for that)

[alexw10]

I am running into this same issue I have the following in my angular.json

"configurations": {
            "production": {
              "optimization": true,
              "outputHashing": "all",
              "sourceMap": false,
              "extractCss": true,
              "namedChunks": false,
              "aot": true,
              "extractLicenses": true,
              "vendorChunk": false,
              "buildOptimizer": true,
              "fileReplacements": [
                {
                  "replace": "src/environments/environment.ts",
                  "with": "src/environments/environment.prod.ts"
                }
              ]
            },

I run ng build --configuration=production

This produces the same chunks everytime:

Anyone have an update on this or how to fix it been open awhile...

[d668]

yep
ng build --prod --aot --configuration=dev
gives me main.js, vendor.js etc without hashes
angular/cli 6.0.8

ok so after adding all properties to

            "dev": {
              "fileReplacements": [
                {
                  "replace": "src/environments/environment.ts",
                  "with": "src/environments/environment.dev.ts"
                }
              ],
              "optimization": true,
              "outputHashing": "all",
              "sourceMap": false,
              "extractCss": true,
              "namedChunks": false,
              "aot": true,
              "extractLicenses": true,
              "vendorChunk": false,
              "buildOptimizer": true
            }

it works fine

[clydin]

@intergleam In CLI 6+ the --prod flag is an alias for --configuration=production. Since the command line above also has --configuration=dev after it, the dev configuration takes priority and nullifies the --prod flag.

[alan-agius4]

Closing as it looks like the issue has been solved with the answers above.

[vdurante]

@alan-agius4 it was not solved. I am having the same issue with Angular CLI: 6.1.3

[z3dmax]

@alan-agius4 it was not solved. I am having the same issue with Angular CLI: 6.1.3

Same issue for me.

Here my specs

Angular CLI: 6.2.3
Node: 8.11.3
OS: win32 x64
Angular: 6.1.8
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router

Package Version

@angular-devkit/architect 0.8.3
@angular-devkit/build-angular 0.8.3
@angular-devkit/build-optimizer 0.8.3
@angular-devkit/build-webpack 0.8.3
@angular-devkit/core 0.8.3
@angular-devkit/schematics 0.8.3
@angular/cdk 6.4.7
@angular/cli 6.2.3
@angular/flex-layout 6.0.0-beta.18
@angular/material 6.4.7
@ngtools/webpack 6.2.3
@schematics/angular 0.8.3
@schematics/update 0.8.3
rxjs 6.3.2
typescript 2.9.2
webpack 4.19.1
>

[mcblum]

I'm also seeing the same issue - the hashes are there but the same every time.

[clydin]

The hashes should only change if you made changes to the code that resulted in the output differing. (e.g., adding several extra spaces to the end of a source file should not change the output).

[Ivan-Perez]

Hashes don't change in my project either even after doing major modifications in the codebase. I have to Ctrl+F5 every time I make changes to reload them.

[mcblum]

@clydin which makes sense as to why it always works in CI but it's not working locally. Is there a way to force it?

[joshuaball]

I was stuck in the same boat as a few others. Build config looked good with regards to output hashing, but major changes to the codebase still wouldn't change the hashes that were generated. I upgraded typescript from 2.7.2 to 2.9.2 for an unrelated issue, and this started working?!? Wanted to share the experience and see if it helps others.

[javierforero]

I have a similar issue. My configuration:

      "configurations": {
            "production": {
              "fileReplacements": [
                {
                  "replace": "src/environments/environment.ts",
                  "with": "src/environments/environment.prod.ts"
                }
              ],
              "optimization": true,
              "outputHashing": "all",
              "sourceMap": false,
              "extractCss": true,
              "namedChunks": false,
              "aot": true,
              "extractLicenses": true,
              "vendorChunk": false,
              "buildOptimizer": true,
              "serviceWorker": true
            },

I am using Angular's ServiceWokerModule and I am triggering an update check every 20secs or so. And it works when I make a simple change I haven't done before. So if I add a console.log() i get a new hash, but if I remove it and rebuild I get the same hash as when I first ran ng build --prod, shouldn't these be unique with every build?

[diegotrp]

@javierforero I had a similar issue, i changed an URL from 'myserviceurl' to 'MyServiceUrl' and ng build --prod was generating the same hash, i had to refactor some code to get a new hash. My guess is that the 'ng build' command doesn't recognize case changes. I'm using Angular 6.1.0.

This is my build configuration:

      "configurations": {
        "production": {
          "fileReplacements": [
            {
              "replace": "src/environments/environment.ts",
              "with": "src/environments/environment.prod.ts"
            }
          ],
          "optimization": true,
          "outputHashing": "all",
          "sourceMap": false,
          "extractCss": true,
          "namedChunks": false,
          "aot": true,
          "extractLicenses": true,
          "vendorChunk": false,
          "buildOptimizer": true
        }
      }

[rsibanez89]

I got the same issue, ng build --prod generates the same hashed file names even if the code is different.
In the log, I see the hash is different but the name of the files is the same.

Maybe something wrong with webpack.

[MrCroft]

@angular/cli: "7.0.6"
@angular/core: "7.0.4"
typescript: "3.1.6"

ng build --prod generates files without hashes AND with sourcemaps
and I have this in angular.json:

          "configurations": {
            "production": {
              "fileReplacements": [
                {
                  "replace": "projects/my-app/src/environments/environment.ts",
                  "with": "projects/my-app/src/environments/environment.prod.ts"
                }
              ],
              "optimization": true,
              "outputHashing": "all",
              "sourceMap": false,
              "extractCss": true,
              "namedChunks": false,
              "aot": true,
              "extractLicenses": true,
              "vendorChunk": false,
              "buildOptimizer": true,
              "budgets": [
                {
                  "type": "initial",
                  "maximumWarning": "2mb",
                  "maximumError": "5mb"
                }
              ]
            }
          }

in package-lock.json I see that webpack version is 4.19.1 (not sure if it matters)

EDIT: I feel like such a newbie :) I was running npm run build --prod thinking I am running ng build --prod. I'm not going to delete the comment, maybe someone else does the same and finds this.
Of course, actually running ng build --prod works fine (or npm run build -- --prod, either way)

[CodeSwimBikeRunner]

We are using ng build --prod

Same configuration.

"production": {
              "fileReplacements": [
                {
                  "replace": "src/environments/environment.ts",
                  "with": "src/environments/environment.prod.ts"
                }
              ],
              "optimization": true,
              "outputHashing": "all",
              "sourceMap": false,
              "extractCss": true,
              "namedChunks": false,
              "aot": true,
              "extractLicenses": true,
              "vendorChunk": false,
              "buildOptimizer": true,
              "budgets": [
                {
                  "type": "initial",
                  "maximumWarning": "2mb",
                  "maximumError": "5mb"
                }
              ]
            }

And our users still have to hit ctrl + f5 to get even major changes.

[mtraynham]

@alan-agius4 @filipesilva, this issue is not fixed as I and others are seeing similar issues with browser caching. It seemingly has to do with files that are lazy-loaded routes. Can you reopen?

Here's a console log from a few days ago, where I encountered the same issue.

From above, chunk 4.ebf18d34's file was cached by the user's browser because the file name was no different than before. The newly created runtime.91a9e189b file is also referencing the same file name, but was expecting different code to be returned by that file when loaded.

node 11.9.0
@angular/cli ~7.3.0
@angular/core ~7.2.3
OS: Mac
Brower: Chrome 71.0.3578.98/Safari 12.0.2

[filipesilva]

I can reopen, but I will reiterate: if we don't have a reproduction that we can follow, we cannot investigate the issue. I haven't yet seen a report that provides anything that I can follow and get the same result as described in this issue.

So please, if you would like this to get fixed, and see it happening on your specific environment, help us by providing exact steps that we can follow on our machines to see the problem. If it happens on your CI but not on your local machine, you might have to figure out what's different between the two.

[mtraynham]

Just reporting back. I haven't been able to recreate this locally, but it's happened a few times in the past. I created a project and test script to rerun builds.

The test script waits for the user to make a code change, then given the go-ahead, recompiles with AOT and diffs all the JS/CSS files with the previous run. If the file name is somehow the same, but the contents are different, it blows up.

I haven't been able to recreate locally with various trials, such as 2 lazy loaded modules depending on a 3rd local dependency, changing only styles, changing only html, etc.

So, instead for our CI build, I wrote a different script that does a similar test. It retrieves the last stable version of the build and does the filename match diff check. If the filenames are the same, but the contents are different, it will blow up. This should at least give me insight into when this occurs or what kind of commit causes it.

If anyone wants a template for that script, it looks like this:

mkdir -p .tmp/last-stable-build
tar -xf .tmp/last-stable-build.tar.gz --directory .tmp/last-stable-build
# Default hashes are 20 character hex
# https://webpack.js.org/configuration/output/#outputhashdigest
# https://webpack.js.org/configuration/output/#outputhashdigestlength
files=$(cd .tmp/last-stable-build && find . -regextype posix-extended -regex ".*[a-f0-9]{20}\.(js|css)")
for i in $files; do
    if [ -f "dist/build/$i" ]; then
        # diff returns a non-standard 0 code when differences are found
        # anything other than 0 will cause our build to fail
        diff -q .tmp/last-stable-build/$i dist/build/$i
    fi
done

[filipesilva]

@mtraynham thank you for taking the time to trace this and help debug it. I understand it's not easy, and the setup you're using must have taken a fair bit of time to put together, but I really appreciate it because at the moment it's the best chance we have at getting to the bottom of it.

[joe704la]

@filipesilva Any updates on this?

[joe704la]

@filipesilva is there a way to force a new hash for every single file even if it hasn't been changed? I know for some people they wouldn't want this, but it actually would help us out on our new releases.

[joe704la]

@filipesilva Any updates? Having a ton of issues with this. I would be okay with a force of changing hash on all files too.

[filipesilva]

@joe704la like I said before, I cannot reproduce it and without a reproduction I cannot fix it. I'm waiting for @mtraynham's results. Maybe you can try and reproduce it in a similar way?

[joe704la]

@filipesilva do you have an answer to the other question about forcing a unique hash for all files after each build and not just changed files?

[filipesilva]

That's not how these hashes work really. We use Webpacks file hashing functionality, and it determines the hash from the file content. If the file content is the same, Webpack makes the same hash. So it's not that we determine what files changed and give them a new hash, but rather that the file content is different and thus gets a new hash.

[joe704la]

@filipesilva okay, that makes sense. Thank you

[mtraynham]

I just want to chime in real quick. I remembered from a while ago, when I was using straight Webpack without Angular CLI, I ran into this particular bug. It suggests hashes are based off the original source and not necessarily the generated output.

Based on that bug's documentation, the chunkhash might not change if:

1. You make a change to the webpack config (e.g. adding/removing/changing a plugin/loader).
2. You upgrade a loader/plugin version.

I didn't have this as a test case when doing local testing for this particular bug (the AngularCLI one).

There may be a case where a user upgrades Angular CLI (and likely Angular), it generates different output from before, but leaves the file hashes the same. I imagine if you had no package-lock file and a very relaxed version of AngularCLI, you may easily encounter that without noticing. Or simply updating your dependencies to latest might cause it.

Or if AngularCLI (and subsequent tools) somehow are non-deterministic and generate different content on every build, the source would be unchanged, but the output is different, running into this particular bug.

[filipesilva]

@mtraynham I am not aware of the build process being non-deterministic for the same set of sources + build dependencies.

The only thing that comes to mind is optimizations and tree-shaking... where the end result of a given chunk differs from the sources.

But the indirection with the webpack module loader used in chunks make cross-chunk optimizations almost impossible for third party tools like Uglify/Terser. So I can't see how changes in one source file could affect another through the action of Uglify/Terser.

Webpack itself also does https://github.com/webpack/webpack/tree/master/examples/side-effects though. But that wholly removes files, and can't partially change content.

[paulsperanza]

I'm seeing the issue also with Typescript 2.9.2, Angular 6.1.4

      "configurations": {
        "production": {
          "optimization": true,
          "outputHashing": "all",
          "sourceMap": false,
          "extractCss": true,
          "namedChunks": false,
          "aot": true,
          "extractLicenses": true,
          "vendorChunk": false,
          "buildOptimizer": true,
          "fileReplacements": [
            {
              "replace": "src/environments/environment.ts",
              "with": "src/environments/environment.prod.ts"
            }
          ]
        }
      }

[filipesilva]

@paulsperanza do you have a reproduction we can follow? If you do, can you please document it here and verify the same happens on your local machine? This is a problem for which we haven't yet seen a reliable reproduction.

[mix5003]

I not quite sure. but i saw some comment can solve by ctrl + f5, in that case i think it not angular relate, but it a web server relate.

some web server (or maybe browser) add a cache headers to text/html and some static file by default. so when user request same url, browser will use cache version of html that reference old files. and i think js/css that html reference may be in cached too. but when user try to load a module that not exists in cache it try to load from server and failed. some thing like

• user open your home page ( url = '/') browser cache html / runtime.js that contain all chunk info and other js
• user go to register module. (url = '/register') browser cache register chunk
• user go to other link (may be verify email)
• you deploy new version and change everything
• user open your home page ( url = '/') browser load html from cache. but that html reference old runtime.js file. and runtime.js and other main file may be use from cache as well. so it reference old hash versions
• user go to login module. (url = '/login') but browser use old runtime.js so it not load new version and try to load old login chunk.
• and from above if user open browser and goto '/login' directly (not come from '/') it will receive new html version because it not cache '/login' page it cache only first page that user open. so it will not cause any problem.

in this case i think you may add Cache-Control headers to force browser re-validate everytime that user request.

if you use nginx this is my sample config. i cache every static files. but if file not exists i force browser to not cache and re-validate everytime.
https://gist.github.com/mix5003/134b041fc4761af1ab348d944e4f810f

[ddhille]

Just faced this behaviour on a SPA, hosted on an Azure Blob storage with Azure Front Door (with dynamic caching activated).
Everytime I released a new version of the app, users had to force-reload the page to get the new version. Because the links to the new assets (like main.XXX.js, ...) are located in the index.html, which has been cached and therefore the old (cached) asset versions getting loaded.

I was able to solve it (within my CD pipeline on Azure DevOps):

1. Let the Azure CLI set the Cache-Control header to "no-cache" on the index.html after pushing it to the blob storage

az storage blob update --account-name $(storageAccount) --container $web --name index.html --content-cache-control no-cache

1. Purge the Front Door cache

az extension add --name front-door
az network front-door purge-endpoint --resource-group $(ressource) --name $(frontdoor) --content-paths "/"

[aburht]

@filipesilva any updates or idea on this issue, this still exists with angular 7x

[filipesilva]

@aburht I'm still waiting for a reproduction. No one has been able to provide me with a reproduction so far.

[aburht]

@filipesilva did some ground work on this, and I assume this is due to index.html getting cached and where in index.html's script tag is referring to old build's chunks, as we know output hashing doesn't provide hashing for index.html, Any thoughts that you could think of it?

[filipesilva]

@aburht what you describe sounds a lot like what @mix5003 and @ddhille describe. And I think it makes sense. But that's not something that should be addressed on Angular CLI, but rather on your hosting caching strategy.

We probably should add something to https://angular.io/guide/deployment about caching for index.html and other resources.

At the end of the day whenever caching is used, you have to decide when to invalidate the cache. That's the hard part of caching really.

And there are several types of cache at play. Your server, reverse-proxy, browser, service-worker. All of these can have caches. So your deployment strategy needs to consider what caches you have up.

[aburht]

@filipesilva exactly I agree, I resolved this issue setting meta tag no cache revalidate, which resolved my issue. Like you said it's a great idea to document it in deployment guide, since we now
know this is not an cli issue, we should be good to close this issue/thread

[rajaramtt]

Any updates on this issue, Still exists with angular 7.x!.

[filipesilva]

@rajaramtt the most recent updates are in the comments directly above yours.

[aburht]

@rajaramtt try setting meta tags to your HTML, set Max age to 0, no cache.
Say if the above approach didn't work,
Try setting the cache control headers to 'no cache' headers in your Apache or IIS server

1. If you are using https configured url, it sets max-age to 0 by default

[mix5003]

i think in some scenario header no cache may not help.
something like

1. user open module1
2. you edit module2 and deploy (may be a hotfix)
3. user go to module2
   in this case angular will try to load module2 from old hash too.
   for me this happen because user open browser and do something then sleep notebook without close browser. and use it again in tomorrow, sometime user use versions that release 7 days ago.

in this case you may set your web server to redirect not found js to some js like reload.js that force page when it reference file that not exists anymore.
like: https://gist.github.com/mix5003/0aff8719804494530790276406499e8c
(this un-tested config. use on your own risk)
or just create you own error handler and add this to check errors.

if (err.message) {
  if (err.message.indexOf('Error: Loading chunk') !== -1) {
    // TODO: be more user friendly
    location.reload(true);
    return;
  }
}

but i still don't know if user open module1 and i want to push hotfix to module1, how to do it.
for now i put build date to environments.ts and force angular send it every request and check it at server side to tell client to force reload in serious case. is this way ok? or someone has a better way?

[alshazly]

Greeting, I face the same issue. I need to re-product the project to see the changes in cloud. Does anyone solve this issue?

[rajaramtt]

Still exists, Please provide an alternative solution.

[10kc-awright]

We've been plagued by a very-hard-to-debug issue for quite a few weeks now that we have since resolved, but I feel it is very closely related to this issue.

We have roughly 90 bundles optimized for different use cases throughout our application, we release every few days as new features clear for production. We upload every bundle that gets created to the same bucket (which means old files would be overwritten if they have the same file name), and we have a cache policy that always requires index.html to be loaded from the CDN, while the bundles have a cacheing policy to let them live forever. So when index.html reloads, it will load any new bundle that has changed as part of the build, this is done through the content hash that is added to the filename.

Since it is a content hash added to the filename in the default angular-cli config and we have so many bundles, we noticed that the names of some bundles wouldn't change. We then noticed that these unchanged bundles (aka their hash/contents didn't change) would fail the browser integrity check on Google Chrome (only Chrome, not IE 11 or Firefox).

I still do not have a good understanding as to why this was the case, because cURLing the files and manually generating the integrity hashes matched what was contained in the index.html and runtime js files that were generated by angular-cli. This lead me to believe it wasn't the hashing that was causing integrity hashes to fail.

It became our assumption that some mechanism was failing the integrity check based on files changing (aka timestamps/metadata) without the filenames changing/being reloaded from cache. This is where I wish I had a better understanding of the root cause, but it seemed fishy that it was only the bundles that didn't change filename hashes between deployments that were causing the issue.

In order to work around this I added a build phase after angular-cli generates the files in dist/ that add a nonce (just the ms since epoch) to every file name, updates the internals of index.html and runtime.x.js and regenerates the integrity hashes (and sticks them where they need to go). Since adding this "cache buster" timestamp we haven't encountered the same cache integrity checking issue, and every bundle gets uploaded/tagged uniquely per deployment now.

I do think this is a Chrome issue and not an angular-cli issue, but I do think that if the hash added to file names was the build hash instead of the content hash it would resolve this issue (for us at least).

[filipesilva]

In the 6 months since I reopened this issue there still doesn't seem to be a reproduction that shows there's a problem with how Angular CLI produces unique hashes for bundles.

There's been a some very informative comments on this issue that point towards how servers and browsers interpret cache requests, like https://github.com/angular/angular-cli/issues/10641#issuecomment-491588141, https://github.com/angular/angular-cli/issues/10641#issuecomment-492714699, and https://github.com/angular/angular-cli/issues/10641#issuecomment-517290830. If you're still seeing cache related problems, I suggest you read through these comments to see if your setup is similar.

I will again close this issue as it's not actionable on Angular CLI. If you see it happening on your specific environment, help us by providing exact steps that we can follow on our machines to see the problem. If it happens on your CI but not on your local machine, you might have to figure out what's different between the two.

[angular-automatic-lock-bot[bot]]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{_This action has been performed automatically by a bot._}