ng build --prod is not creating unique hashes #10641

JohnGalt1717 · 2018-05-04T14:56:39Z

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

Create a site with ng new
Add a lazy path with loadChildren
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 · 2018-05-04T17:56:59Z

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 · 2018-05-04T19:03:06Z

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 · 2018-05-04T19:05:14Z

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 · 2018-05-04T19:10:25Z

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 · 2018-05-04T19:27:53Z

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 · 2018-05-04T19:41:18Z

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 · 2018-05-04T19:45:32Z

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 · 2018-05-15T14:50:43Z

This is still an issue with 6.0.1

filipesilva · 2018-05-15T15:41:36Z

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 · 2018-05-15T15:54:21Z

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 · 2018-06-26T07:53:09Z

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 · 2018-06-26T09:41:19Z

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 · 2018-07-02T08:34:09Z

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 · 2018-07-02T13:15:32Z

@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 · 2018-07-02T13:20:38Z

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 · 2018-07-26T18:31:57Z

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 · 2018-08-21T09:51:21Z

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 · 2018-08-21T17:20:19Z

@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 · 2018-09-03T06:50:49Z

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

vdurante · 2018-10-04T23:29:36Z

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

z3dmax · 2018-10-09T09:10:29Z

@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 · 2018-10-16T15:48:41Z

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

clydin · 2018-10-16T15:53:25Z

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 · 2018-10-16T16:02:49Z

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 · 2018-10-16T16:02:55Z

@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 · 2018-10-19T00:42:05Z

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.

filipesilva · 2019-02-26T16:37:14Z

@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.

TronActive · 2019-03-01T15:00:35Z

@filipesilva Any updates on this?

TronActive · 2019-03-04T15:33:46Z

@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.

TronActive · 2019-03-12T20:31:44Z

@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 · 2019-03-12T20:41:07Z

@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?

TronActive · 2019-03-12T20:43:47Z

@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 · 2019-03-12T20:47:17Z

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.

TronActive · 2019-03-12T20:50:14Z

@filipesilva okay, that makes sense. Thank you

mtraynham · 2019-03-12T21:12:53Z

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:

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

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 · 2019-03-14T10:18:15Z

@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 · 2019-03-15T20:05:33Z

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 · 2019-03-28T10:09:33Z

@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 · 2019-05-12T11:41:09Z

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 · 2019-05-15T15:55:39Z

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):

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

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 · 2019-06-06T15:11:47Z

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

filipesilva · 2019-06-06T21:15:42Z

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

aburht · 2019-06-07T10:24:18Z

@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 · 2019-06-07T13:01:22Z

@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 · 2019-06-07T16:53:11Z

@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 · 2019-06-11T12:58:43Z

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

filipesilva · 2019-06-11T13:13:04Z

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

aburht · 2019-06-11T14:56:16Z

@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
2. If you are using https configured url, it sets max-age to 0 by default

mix5003 · 2019-06-12T04:32:30Z

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

user open module1
you edit module2 and deploy (may be a hotfix)
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 · 2019-07-18T23:20:01Z

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 · 2019-07-25T09:21:05Z

Still exists, Please provide an alternative solution.

10kc-awright · 2019-08-01T13:35:25Z

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 · 2019-08-15T09:53:19Z

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 #10641 (comment), #10641 (comment), and #10641 (comment). 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 · 2019-09-15T08:02:07Z

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.}

filipesilva closed this as completed May 4, 2018

filipesilva reopened this May 4, 2018

filipesilva added the needs: repro steps We cannot reproduce the issue with the information given label May 4, 2018

alan-agius4 closed this as completed Sep 3, 2018

filipesilva closed this as completed Aug 15, 2019

angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 15, 2019

ng build --prod is not creating unique hashes #10641

ng build --prod is not creating unique hashes #10641

Comments

JohnGalt1717 commented May 4, 2018 • edited Loading

Versions

Package Version

Repro steps

Observed behavior

Desired behavior

Mention any other details that might be useful (optional)

filipesilva commented May 4, 2018

JohnGalt1717 commented May 4, 2018

JohnGalt1717 commented May 4, 2018

filipesilva commented May 4, 2018

JohnGalt1717 commented May 4, 2018

filipesilva commented May 4, 2018

JohnGalt1717 commented May 4, 2018 • edited Loading

JohnGalt1717 commented May 15, 2018

filipesilva commented May 15, 2018

JohnGalt1717 commented May 15, 2018

davitPetrosyanT commented Jun 26, 2018

simmash commented Jun 26, 2018

ghost commented Jul 2, 2018 • edited by ghost Loading

clydin commented Jul 2, 2018

ghost commented Jul 2, 2018

alexw10 commented Jul 26, 2018

d668 commented Aug 21, 2018 • edited Loading

clydin commented Aug 21, 2018

alan-agius4 commented Sep 3, 2018

vdurante commented Oct 4, 2018

z3dmax commented Oct 9, 2018 • edited Loading

mcblum commented Oct 16, 2018

clydin commented Oct 16, 2018

Ivan-Perez commented Oct 16, 2018 • edited Loading

mcblum commented Oct 16, 2018

joshuaball commented Oct 19, 2018

filipesilva commented Feb 26, 2019

TronActive commented Mar 1, 2019

TronActive commented Mar 4, 2019

TronActive commented Mar 12, 2019

filipesilva commented Mar 12, 2019

TronActive commented Mar 12, 2019

filipesilva commented Mar 12, 2019

TronActive commented Mar 12, 2019

mtraynham commented Mar 12, 2019 • edited Loading

filipesilva commented Mar 14, 2019 • edited Loading

paulsperanza commented Mar 15, 2019 • edited Loading

filipesilva commented Mar 28, 2019

mix5003 commented May 12, 2019 • edited Loading

ddhille commented May 15, 2019

aburht commented Jun 6, 2019

filipesilva commented Jun 6, 2019

aburht commented Jun 7, 2019

filipesilva commented Jun 7, 2019

aburht commented Jun 7, 2019 • edited Loading

rajaramtt commented Jun 11, 2019

filipesilva commented Jun 11, 2019

aburht commented Jun 11, 2019

mix5003 commented Jun 12, 2019 • edited Loading

alshazly commented Jul 18, 2019

rajaramtt commented Jul 25, 2019

10kc-awright commented Aug 1, 2019

filipesilva commented Aug 15, 2019

angular-automatic-lock-bot bot commented Sep 15, 2019

JohnGalt1717 commented May 4, 2018 •

edited

Loading

JohnGalt1717 commented May 4, 2018 •

edited

Loading

ghost commented Jul 2, 2018 •

edited by ghost

Loading

d668 commented Aug 21, 2018 •

edited

Loading

z3dmax commented Oct 9, 2018 •

edited

Loading

Ivan-Perez commented Oct 16, 2018 •

edited

Loading

mtraynham commented Mar 12, 2019 •

edited

Loading

filipesilva commented Mar 14, 2019 •

edited

Loading

paulsperanza commented Mar 15, 2019 •

edited

Loading

mix5003 commented May 12, 2019 •

edited

Loading

aburht commented Jun 7, 2019 •

edited

Loading

mix5003 commented Jun 12, 2019 •

edited

Loading