Unique content hash per build

[martinfrancois]

🚀 Feature request

Command (mark with an x)

• new
• build
• serve
• test
• e2e
• generate
• add
• update
• lint
• extract-i18n
• run
• config
• help
• version
• doc

Description

We experienced a similar issue to what is described in #10641 (comment) in the past, with one of them being just recently. The situation is the following: we make a build and deploy it, some customers use the website and in this process cache the JS files. We make some changes to the codebase and then one week later we make another build and deploy it. One of the JS files in the new bundle has the same content hash (and file name) but a different intergrity hash. This leads to customers complaining about bugs, because the browser still has the file cached from the old build, but since the integrity hash is different (and we don't cache the index.html file) the integrity check fails as the cached JS file from the old build is hashed against the integrity hash from the new build, which causes the browser to block the JS file.

The problem is that we can't reproduce this behavior, when we try to locally build the same commit hashes that were deployed, the contents of the JS files of the two builds are identical. In the last case the JS file from the old build always included an exception variable in the catch blocks (} catch (n) {), while the new build omitted them (} catch {) with everything else being equal (we also didn't change any dependencies or configuration). Since we can't reproduce it I can't open a bug for this, but this is a big issue for us.

Currently, outputHashing can only be configured to generate a content hash. If it was possible to configure outputHashing to always create unique file names on every build, while it would not fix the underlying issue, it would resolve the problem, since when deploying a new build we could be sure the browsers would not already have a cached file with the same name and the file would not be blocked from execution as the integrity check wouldn't fail.

Describe the solution you'd like

Add another configuration option next to outputHashing which would allow to define whether the file names generated as part of outputHashing should be based on the file content (current behavior, default) or be unique with each build (new).

To ensure the file names are unique per build, one option would be adding an epoch timestamp to the filenames, either in replacement of the content hashes or additional to them. So the file names would look something like this main.1657103379.js or main.eaf4225277726a91.1657103379.js. Another option would be to include an epoch timestamp / randomness when calculating the content hash.

Describe alternatives you've considered

An alternative would be fixing the underlying issue, as that would also fix the problem. But as I mentioned the issue is not reproducible and very sporadic. Seeing there are quite a lot of issues already here on this topic but no one so far has been able to make it reproducible I don't think it's likely this is a viable solution, unless someone from reading the issue description of the differently written catch clauses knows what the issue is.

A workaround would be for us to do the same as described in #10641 (comment) to add a post build script which would manually transform the file names to include the timestamp. But this would be quite a brittle solution, as it could break at any point, should Angular introduce changes in the way the files are built or named.

[alan-agius4]

Root cause of the issue is #22906

[angular-automatic-lock-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.}