fix avoid-cascade testcase

[sokra]

This fixes a few problems with the avoid-cascade test cases for rollup and webpack.

The description claims that the import-map is uncachable, but this can't be the best practice, considering that it's easily possible to make it cacheable for rollup and it's already cacheable by default for webpack. So it changed the description and updated the rollup plugins to avoid inlining the import-map and add a hash instead.

The example code never used an asset in an on-demand loaded part of the application. Without that webpack would just pass the test with the defaults (initial chunks do not have hashes in the runtime chunk, so it won't case a cascade). I added another asset in an on-demand-loaded chunk to make the test case more difficult (and more real worldy). Now webpack would really fail this test case with the defaults. I added a few lines of description to explain why this is the default. (TL'DR: in larges apps # of assets >> # of chunks, so we go with one-level cascade to allow loading asset hashes on demand and avoid a huge import-map)

Anyway webpack allows to configure caching behavior for each module with the splitChunks.cacheGroups configuration and you can move the asset hashes anywhere you like to, e. g. into the runtime...

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

:memo: Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[sokra]

@googlebot I signed it!

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[googlebot]

All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter.

We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only @googlebot I consent. in this pull request.

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

[jakearchibald]

It seems to work. I'm not sure if all these config switches are actually documented to do the things they end up doing.

[developit]

Just double checking something here: I think my wording may have been misleading regarding "uncacheable" - what I meant was that the mapping (in webpack's case runtime.js) is not permanently cacheable, since it doesn't have a hash. Perhaps that's moot though, since it could be hashed and referenced with that hash from the HTML document that then becomes the time-based invalidator?

[jakearchibald]

Thanks @sokra and @developit!