Angular-cli: localized components containing i18n tags will produce identical chunk hashes when building with --localize

Created on 7 Apr 2020  ยท  9Comments  ยท  Source: angular/angular-cli

๐Ÿž Bug report

Command (mark with an x)

  • [ ] new
  • [x] build
  • [ ] serve
  • [ ] test
  • [ ] e2e
  • [ ] generate
  • [ ] add
  • [ ] update
  • [ ] lint
  • [ ] xi18n
  • [ ] run
  • [ ] config
  • [ ] help
  • [ ] version
  • [ ] doc

Description

I have an application that is being translated in several (21 at the moment) languages using the Angular i18n mechanism. I'm compiling the app AOT, therefore I need a separate build for each locale. To achieve this I setup my Azure pipeline to build the app using multiple agents in parallel, one for each locale, and it works like a charm. However, this is very resource-consuming, so I'm updating to Angular 9 in order to use the --localize option, which perfectly fits my needs.
After the update I can build the app once and translate it to all languages in a few seconds, which is amazing.
I am now facing this issue: when I build my application for all locales, the resulting chunk hashes are identical. As a result, browser cache is not invalidated and files are not re-requested, so the app is not translated.

๐Ÿ”ฌ Minimal Reproduction

  • clone this repo
  • run npm install
  • run ng build --localize
  • check the dist folder: file content for main.js is different for each locale (template text is translated), while the hashes are the same

๐ŸŒ Your Environment


Angular CLI: 9.1.0
Node: 10.19.0
OS: win32 x64

Angular: 9.1.0
... animations, cli, common, compiler, compiler-cli, core, forms
... language-service, localize, platform-browser
... platform-browser-dynamic, router
Ivy Workspace: Yes

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.901.0
@angular-devkit/build-angular     0.901.0
@angular-devkit/build-optimizer   0.901.0
@angular-devkit/build-webpack     0.901.0
@angular-devkit/core              9.1.0
@angular-devkit/schematics        9.1.0
@ngtools/webpack                  9.1.0
@schematics/angular               9.1.0
@schematics/update                0.901.0
rxjs                              6.5.5
typescript                        3.8.3
webpack                           4.42.0

Anything else relevant?
In my scenario, the user language preference is stored in the cookies, and a shell app serves the corresponding folder. I can't add the locale to the URL.
Therefore in my angular.json I set baseHref="/" for all locales.

I am aware of this issue and the PR mentioned there, however the issue is still not resolved.

devkibuild-angular feature

Most helpful comment

16526 was never addressed and was closed without resolution. #16817 fixes a separate issue, where the hashes would remain the same when rebuilding after changing translations and not changing code.

This exact case of the file hashes being the same for different locales is still present. It was considered a regression in #16526, but has since been reclassified as a feature.
Quite an annoying regression, that prevents having flat file structures.

All 9 comments

Seems like it was supposed to be fixed with https://github.com/angular/angular-cli/pull/16817 but I am having the same issue with@angular/[email protected]

I'm also having this issue.

My repro: https://github.com/pjm0616/pastebin/tree/202004-angular-localize-outputhash
@angular and @angular-devkit version: 9.1.3
I've also included the build output in the repo.
The dist-localize folder contains the build output with localize=true, and the dist folder was built separately for each locale without localize=true.

$ npm run buildall
$ sha1sum dist{,-localize}/*/main-es5*.js
6e0407f00e27d877cb8bbcf0d7b069dfcc42cb8b  dist/en/main-es5.27d2d00de67fb6cace7d.js
bc09ba481672f092a359949c6d55b14e319fc63a  dist/ko/main-es5.54a148db9b0b5fb29549.js
6e0407f00e27d877cb8bbcf0d7b069dfcc42cb8b  dist-localize/en/main-es5.54a148db9b0b5fb29549.js
bc09ba481672f092a359949c6d55b14e319fc63a  dist-localize/ko/main-es5.54a148db9b0b5fb29549.js

16526 was never addressed and was closed without resolution. #16817 fixes a separate issue, where the hashes would remain the same when rebuilding after changing translations and not changing code.

This exact case of the file hashes being the same for different locales is still present. It was considered a regression in #16526, but has since been reclassified as a feature.
Quite an annoying regression, that prevents having flat file structures.

I agree with @bridzius that #16817 fix only a symptom of the more deep issue of #16526.

I also have the same hash for multiple main.hash.js files that don't have the same content due to Angular i18n post compilation change.

(Side note, I think that, even if I'm not 100% sure, it mess with Angular service worker itself when I switch between translations of my app).

@clydin in https://github.com/angular/angular-cli/issues/16526#issuecomment-582366860 you say I quote:

Removing the use of webpackโ€™s file hashing and moving the file name creation to a later stage of the build process is currently planned. However, such a change is out of scope within the current release candidate period.

It seems like the right things to do to fix this issue.
But you didn't post any link. Can you tell where we could upvote for this solution, or even help?

(@nas90 thanks for (re-)opening this issue!)

@alan-agius4 any updates on this one?

Recently migrated to Angular 9 and faced this issue. Was really disappointing to see this. Even the different configurations for different languages (for example --configuration=production,de and --configuration=production,fr, plus properly set angular.json as Documentation advises) lead to the same hashes. This means that there is only a one way to get the flat files deployment working โ€“ to use the deprecated build parameters --i18nLocale, --i18nFile and --i18nFormat ๐Ÿ˜ž

Just tried on latest Angular (10.0.5) and I'm still facing this issue ๐Ÿ˜ข

This issue is still open hence it hasnโ€™t been addressed yet.

While this is on our radar, there are issues which have a higher priority.

PRs to implement this feature are welcome.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

hartjo picture hartjo  ยท  3Comments

rwillmer picture rwillmer  ยท  3Comments

delasteve picture delasteve  ยท  3Comments

daBishMan picture daBishMan  ยท  3Comments

rajjejosefsson picture rajjejosefsson  ยท  3Comments