[worklets] could the module responses cache and custom fetch steps be simplified?

[domenic]

I just realized that instead of customizing the fetch step, you might be able to get away with something simpler. Namely, say:

"Each Worklet has a module map, which is a module map, initially empty.

Then, in the definition of [set up a worklet environment settings object], say that your module map algorithm returns the associated Worklet's module map.

And then, remove the "perform the request" customization entirely.

Also, update to use fetch a module worker script tree and check that the arguments match, as that changed a bit.

I think this works!? The whole point of this customization was just to get a module map that's shared across all WorkletGlobalScopes associated with a given Worklet, right? But if that's the case, it's easy to accomplish just by customizing the WorkletGlobalScope's environment settings object's module map algorithm.

[bfgeek]

Discussed privately out of band, the reason for the hook is that a script object is tied to a global scope so we can't share the module map between globals :(.

Addressing the fetch a module worker script tree in PR #375

[domenic]

Note that service workers have also run into an issue where scripts being tied to globals is inconvenient for them and their caching logic. We might end up introducing some global-agnostic concept at some point. However I kind of doubt it will help things too much in the manner described here. If it does I'll circle back with a PR.