Question: Evaluating unchanged URL after updating Import Maps

[adamseckel]

I'm having a hard time getting es-module-shims (not in shim mode) to reevaluate a module at a url when the url doesn't change, but the import map changes how it's dependencies should be resolved, and I wondered if you could help me understand if this is possible.

We have a module like:

// https://framer.com/modules/webPage/yyy.js
import Component from "#framer/component/xxx.js"

We initialise the import map with { "#framer/component/xxx.js": "https://framer.com/modules/component/xxx-1.js" }, and call window.importShim("https://framer.com/modules/webPage/yyy.js"). That evaluates the module and stores it to the registry in es-module-shims. The evaluation result runs the xxx-1.js version of the component.

Then if we generate a new version of the xxx component, we await updating the import map: { "#framer/component/xxx.js": "https://framer.com/modules/component/xxx-2.js" }, and await a call to window.importShim("https://framer.com/modules/webPage/yyy.js") again to get the latest evaluation result with the new dependency.

Unfortunately doing that causes es-module-shims to reuse the previous evaluation result, because the we are providing the same URL, which is hitting the registry in shims, which reuses the blob / evaluation result that shims created on the first evaluation. This results in window.importShim() returning the previous evaluation result.

Should this be possible or is this not an intended use case? Or is there some API we need to call to clear the item from the registry? Or someway that updating the import map should result in a cleared registry? I naively assume it should be possible since this is a great use case to dynamically evaluate modules, but please let me know if I've made an incorrect assumption or have misunderstood some of the shims code.

I could also work around the registry caching by adding a pointless query parameter to the URL with a random value whenever I know the import map has been updated, but then this feels a little bit dirty. Maybe it's fine though since loadAll should reuse unchanged dependencies from seen.

Any help would be very appreciated!

[guybedford]

Modules are not generally hot reloadable in browsers according to the modules spec, therefore building a hot reloading system on top of a standards compliant loader always requires using ?v=versionIndex additions to the URLs to manage versioning.

The alternative to this model is to use an IFrame, and then clear the IFrame and reload all modules every time there is a change.

These are the two standards compatible techniques, and es-module-shims as a standards compatible loader works with both. Trying anything else is going to be a hard time.

We do have a full hot reloader plugin support in this PR, which builds on the first approach - #269 I just never landed it as I wanted to get some more feedback first on the model. If you're interested in something like this happy to share some examples on that too as it might be an easier "out of the box" approach.

[adamseckel]

Thanks so much for clarifying @guybedford! That makes sense to me, I agree moving too far away from the spec is not worthwhile -- I just wasn't sure if the dynamic mode which i know is already not in the spec should account for this.

We already have quite a lot of infrastructure that gives us the ability to quite deterministically call importShim() with an updated query parameter only the import map changes, so for now, I think that draft PR was perfectly helpful as is just to clarify how you imagine this could work and give us confidence to take a similar approach.

Thanks again for your help!