Angular-cli: --localize produces files with same hash values, even though file contents are different

[mstawick]

🐞 Bug report

Angular CLI: 9.0.0-rc.7, Angular: 9.0.0-rc.7

Command (mark with an x)

• [ ] new
• [x] 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

[filipesilva]

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]

FYI, it messes up source maps as well.

[filipesilva]

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.

[thekip]

One of the possible solutions might be re-hashing file names and replace links in index.html as an additional step in localize postprocessor.

This also may have a benefit of implementation flat mode for localize, by adding locale code to a filename:

index.en.html
main.en.%hash%.js
index.pl.html
main.pl.%hash%.js

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.

[thekip]

BTW it looks not so complicated to just replace names of lazy chunks in runtime bundle

// example webpack runtime code
/******/    function jsonpScriptSrc(chunkId) {
/******/        return __webpack_require__.p + "" + ({"cars-search-ui":"cars-search-ui","filestack-client":"filestack-client","flights-api-parsing":"flights-api-parsing","flights-search-ui":"flights-search-ui","td":"td"}[chunkId]||chunkId) + ".js"
/******/    }

But the question about how ugly is that and does that kind of solution acceptable for that project is still opened.

[thekip]

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]

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 (https://github.com/angular/angular-cli/pull/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.

[thekip]

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 https://github.com/angular/angular-cli/pull/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]

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