#980: Multiple import maps

Visit on Github.

Opened Aug 9, 2024

こんにちは TAG-さん!

I'm requesting a TAG review of multple import maps (née "dynamic import maps").

Import maps currently have to load before any ES module and there can only be a single import map per document. That makes them fragile and potentially slow to use in real-life scenarios: Any module that loads before them breaks the entire app, and in apps with many modules the become a large blocking resource, as the entire map for all possible modules needs to load first.

This proposal is to enable multiple import maps per document, by merging them in a consistent and deterministic way.

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • Relevant time constraints or deadlines: Hoping to ship by EoY
  • The group where the work on this specification is currently being done: HTML
  • The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): HTML
  • Major unresolved issues with or opposition to this specification: None AFAIK
  • This work is being funded by: Shopify

Discussions

2024-10-14

Minutes

<blockquote>

We looked at this today, and it seems like a very nice improvement to the platform. The devil will be in the details, of course. It looks like you're working those out in the right place. Please keep doing that, and good luck.

</blockquote>

Then a question:

If querying the map causes the queried mapping to be fixed (otherwise, the introduction of a new mapping will result in a change to the already-retrieved mapping) then does that not potentially lead to non-deterministic outcomes? The value of mappings will depend on the order of import map availability and queries to the import map. This is partly addressed by the fact that a module graph uses a consistent mapping, but that doesn't help at the top level where the loading order of modules might not be deterministic. Also, why should a miss (a mapping that a module graph attempts to resolve, but fails) be treated differently, as it appears to be?

Jeffrey: This and https://github.com/w3c/tpac2024-breakouts/issues/31 / https://github.com/WICG/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md seem related, unless I'm mixing up module maps and import maps.

<blockquote>

At first glance, this looks great. We had a few questions:

  • As we understand it, the requirement to ensure that a mapping cannot change is hard to meet. It looks like a resolved mapping has the effect of fixing that mapping so that new additions to the map don't change it. How do you avoid nondeterminism? We see that you require the mapping to be stable while loading a module graph, but what about between different graphs? We're thinking about top-level async module loading here and we're not clear on how this might interact with that.
  • If a mapping is used, but does not resolve successfully (perhaps because no mapping exists) is that a state that needs to persist? Why is that safe?
  • The discussion in https://github.com/w3c/tpac2024-breakouts/issues/31#issuecomment-2387141476 seemed to indicate that server-rendered custom elements would want to add inlined CSS modules to the module map as they're sent to the client. Does that need support from this proposal, and if so does this proposal support it? cc/ @justinfagnani @rniwa
</blockquote>
2024-10-21

Minutes

satisfied:

<blockquote>

Thank you for the discussion. We're happy to see this proceed through the HTML review process.

</blockquote>
2024-10-28

Minutes

Closed after previously saying we're OK.