Repository navigation
--localize produces files with same hash values, even though file contents are different #16526
Description
🐞 Bug report
Angular CLI: 9.0.0-rc.7, Angular: 9.0.0-rc.7
Command (mark with an x)
- new
- build
- serve
- test
- e2e
- generate
- add
- update
- lint
- xi18n
- run
- config
- help
- version
- doc
Is this a regression?
Not sure, I haven't used localization with prior versions.
Description
If I have two locales configured, build process will generate two sets of files, one per locale, but the file names (including hash parts) are identical for corresponding files in both sets, even though contents of the files are different due to translations.
🔬 Minimal Reproduction
Have a project with two locales set up, and translated messages in place. Then build it using --localize option and compare file names in resulting localized builds.
🔥 Exception or Error
No error.
🌍 Your Environment
Angular CLI: 9.0.0-rc.7
Node: 12.14.0
OS: linux x64
Angular: 9.0.0-rc.7
... 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.900.0-rc.7
@angular-devkit/build-angular 0.900.0-rc.7
@angular-devkit/build-optimizer 0.900.0-rc.7
@angular-devkit/build-webpack 0.900.0-rc.7
@angular-devkit/core 9.0.0-rc.7
@angular-devkit/schematics 9.0.0-rc.7
@angular/cdk 9.0.0-rc.6
@angular/material 9.0.0-rc.6
@angular/material-moment-adapter 9.0.0-rc.6
@ngtools/webpack 9.0.0-rc.7
@schematics/angular 9.0.0-rc.7
@schematics/update 0.900.0-rc.7
rxjs 6.5.3
typescript 3.6.4
webpack 4.41.2
Activity
filipesilva commentedon Jan 3, 2020
I think this is a regression because localization used to happen on an earlier part of the build pipeline, but now happens as a post-processing step.
mstawick commentedon Jan 8, 2020
FYI, it messes up source maps as well.
filipesilva commentedon Jan 29, 2020
Pinning this issue as we don't yet have a resolution and it will likely affect 9.0.
This might be especially bothersome if you have caching based on the hashes, and one doesn't change when you only do translation file changes. The workaround is to introduce code differences in each affected bundle source. This isn't ideal, and we're working on a fix.
timofei-iatsenko commentedon Jan 31, 2020
One of the possible solutions might be re-hashing file names and replace links in
index.htmlas an additional step in localize postprocessor.This also may have a benefit of implementation
flatmode forlocalize, by adding locale code to a filename:But the open question is how without too dirty hacks teach webpack runtime to fetch correct lazy chunks, because their names will be also changed by hashing.
timofei-iatsenko commentedon Jan 31, 2020
BTW it looks not so complicated to just replace names of lazy chunks in runtime bundle
But the question about how ugly is that and does that kind of solution acceptable for that project is still opened.
timofei-iatsenko commentedon Jan 31, 2020
Well, I see that you actually doing this for differential loading. So it shouldn't be a big deal to add localizing to this as well.
clydin commentedon Feb 4, 2020
The underlying functional issue is that the hashes do not change if only translation file changes are made (and no code changes). In this situation and if the application deployment uses permanent caching strategies for the files then an end-user that has previously cached the file would then not see the updated translation. This PR (#16817) corrects this issue by incorporating the content of used translation files into the file hash calculation. This will prevent the stale cache issue from occurring.
As an aside, Webpack's calculated hash values are not a direct hash of the final content but rather a complex internal calculation based on a variety of factors including such elements as modules referenced and plugins present in the Webpack configuration.
timofei-iatsenko commentedon Feb 5, 2020
Just out of curiosity, does it have any sense to have "complex internal calculation based on a variety of factors" when presence of a plugin or a module anyway will change output and therefore change hash and if no, so there no sense to change a hash (content is not changed).
An aside changes made in PR #16817 will introduce changes in hash for every language even if you change one line in one of them, forcing users to redownload everything.
clydin commentedon Feb 5, 2020
That is the behavior of Webpack itself and is not particular to the Angular CLI. A change in the versions of underlying Webpack dependent packages can cause the hash value to change, for instance.
As to the hash changes, that is true assuming no code changes were made within the application release and only changes to translations for one particular locale were made for that release and none of the build tools were updated since the prior release. While all of this is a possibility, it was also considered to be far more uncommon than common; while the elimination of the potential for stale applications is a necessity.
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.
angular-automatic-lock-bot commentedon Mar 7, 2020
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.