Dynamic import maps support

[guybedford]

It seems like injecting import maps into the page after the first load is explicitly prohibited here:

Similarly, attempting to add a new <script type="importmap"> after any module graph fetching, or fetching of import: URLs, has started, is an error. The import map will be ignored, and the <script> element will fire an error.

This seems very restrictive to me. If the composition rule of import maps was to have them throw on conflicts, then the nondeterministic effects can be reduced here (at least for bare package imports).

This is something users will definitely request as soon as they start using this API. Sandboxes entirely rely on being able to do this sort of thing.

[domenic]

I'm not sure what you're asking for here. Once modules have begun fetching, we can't change mid-flight how module resolution works, so this constraint is very necessary. At the same time, it seems clearly documented. What is the action item?

[guybedford]

Once modules have begun fetching, we can't change mid-flight how module resolution works

It could be possible to move from a state where import('asdf') throws for having no map, to a state where import('asdf') works out due to a map being dynamically injected. This can be a well-defined transition.

I know you have reservations on the determinism here but I would argue that this is an important feature to have, if not initially, that it will be needed eventually.

The action item would be to lay the groundwork for the above determinism by throwing when a package map name collides during composition.

The full behaviour for a deterministic dynamic injection would then be:

• It does not delay the resolver, only those package maps initial on page load delay the resolver
• Once loaded, it composes into the package map, throwing on conflicts with existing packages
• If there are any URL mappings, these throw as well as they are not supported for the dynamic case.
• On its load event, an import() to any name in the new map can then be guaranteed to work.

[domenic]

That's a strange and crippled subset of the functionality that import maps provide; I don't think it makes sense to integrate it into this proposal. Rather, folks should investigate different workflows, e.g. server-generating their import maps. Import maps really aren't designed around dynamism, and it is a non-goal to support that; they have a hard enough job already solving all their existing goals without also taking on the role of a dynamic resolver system.

[guybedford]

Import maps really aren't designed around dynamism, and it is a non-goal to support that; they have a hard enough job already solving all their existing goals.

This sounds more like an opinion than an argument. But yes, it does come down to discussing goals. I can tell from experience that this will be the top requested feature of import maps as soon as users use them.

[domenic]

No, it's more that if we had a different set of goals, we would have designed a different solution, e.g. one based on JavaScript functions instead of declarative JSON structures.

I suggest those interested in adding dynamic mapping to the platform work on doing that in a different manner, and not trying to extend this proposal to encompass it.

[guybedford]

@domenic JS module loaders like RequireJS and SystemJS have provided dynamic mappings through a JSON mapping structure for years, so I don't think the design argument holds on that point here.

[jolyndenning]

For whatever it's worth, I agree that dynamically adding an import map in the browser is a very worthwhile feature. Even after initial module loading has begun. I think it only makes sense for modules that are loaded after the initial page load (either via import() or via injecting a <script type="module"> after initial page load), but I find those use cases compelling.

I'm not sure if I understand all of the nuances of the argument about determinism, but it seems to me that if the user does import('my-lib') before they have defined my-lib in an import map, that that's quite reasonable as a user that my import doesn't work. And also that I'd like to import some modules with an initial import map before adding a new import map that has a few more modules.

[blittle]

Agreed with @joeldenning. If the browser has never evaluated import('some-lib'), then why would it be bad to interpret a new package map that defines some-lib even after other modules have been loaded?

[littledan]

To explain the reasoning here, in the draft import maps specification, HTML doesn't really keep track of whether it's done import("./some-lib.mjs") yet--what it keeps track of is what `"./some-lib.mjs" resolved to via the import map, and whether that was requested yet. I think it'd be a bit surprising if you had an API that observably changed what a particular import statement or dynamic import with the same argument does over time.

At the same time, it's true that the dynamism in this proposal is very limited. Although it's nice that you can use scripts to modify it, any use of <link rel="modulepreload"> will block further import maps from taking effect. It'd take a pretty opinionated page to be able to actually dynamically load more import maps.

I'm wondering what problems people have with this static design. My intuition is, if these things can be pre-computed, it could lead to faster page load time, so I like the design of the import maps proposal. What wouldn't fit in well to #92 (comment) ?

[isidrok]

I think being able to load import-maps dynamically would be beneficial specially for SPAs.

We are currently using some sort of map for long term caching of static assets with RequireJS and the whole file would be huge if it was not split and loaded on demand.
Other concern I have is the performance penalty from fetching multiple maps at the start of the application if different parts of it were deployed in different servers or CDNs.
Finally some existing pages with complex setups heavily rely on adding some mappings from withing the application (i.e. environment/user dependent configuration) and being able to have a single module system is good for managing complexity.

Regarding:

I think it'd be a bit surprising if you had an API that observably changed what a particular import statement or dynamic import with the same argument does over time.

Maybe merging dynamically loaded maps could behave in a way in which the current one take precedence when coming across duplicated keys.

[jhnns]

We are currently using some sort of map for long term cache of static assets with RequireJS and the whole file would be huge if it was not spitted and loaded on demand.

For me, that's the most compelling argument. In general, I can't imagine that you want to alter the way how imports are resolved. But you certainly want to extend it.

[littledan]

I'm a little unclear on the setup. How do you want to use import maps here?

[isidrok]

I'm a little unclear on the setup. How do you want to use import maps here?

Imagine an app with some common modules to all routes and a big module foo which is loaded when navigating to /foo. Module foo has lots of sub-routes and requires lots of static assets so the import-map needed for it to work is quite big. I would like to be able to load foo import-map just before loading the foo module. If having a big SPA the amount of modules like foo could be quite big, thus resulting in quite a big import-map specially if we include information for using import: URLs.

Another use case would be for example for A/B testing or feature toggles: I may want to offer a given set of users a new version of some module while others keep using the old one, this is definitely doable without dynamic import-maps:

// foo.js
import new from './foo.new.js';
import old from './foo.old.js'

const foo = useNew ? new : old;
export default foo;

But may be nicer using them.

In my current setup (nothing serious, just a PoC) I use import-maps for:

• Decoupling in general.
• Resolving the different app-modules though bare imports which allows for partial builds/updates only by updating the import-map.
• Implementing long term caching aliasing bare specifiers to hashed files. I.e. '@x/foo' : 'foo.asd123.js'

I don't have the need for dynamic import-maps here since I use rollup to bundle each module or sub-app and it takes care of dynamic imports and assets, but if I didn't use a bundler then a good number of entries would be written into the map which in most cases would be just fine but who knows how much could it grow.

I could definitely pass without the dynamic behavior of import-maps but I'm used to it while using different module loaders and I think it can be convenient.

[littledan]

@isidrok I'm missing something--why would the import map be dynamic, as opposed to what you dynamically choose to import with import()?