Slim down to a minimal core

[domenic]

This re-focuses the import maps explainer and specification on a minimal core which is more likely to be implementable and agreeable in the near future. It removes multiple import map support, fallback support, and built-in module support for now. The explainer contains a "Further work" section which details these and other potential future work.

In terms of normative changes:

• The parser now rejects non-string addresses, so arrays and null are no longer valid
• The resolver becomes much simpler due to this change, as well as the removal of built-in module support
• There is no more procedure for merging import maps
• Script fetches only wait on a single "pending import map script" instead of a "list of pending import map scripts"
• Any further import maps are not parsed, and generate "error" events on their <script> elements

---

This is not ready to merge yet as I've only updated the reference implementation (not spec) for parsing and resolving. All the content is there though, so this could be reviewed as-is.

---

Preview | Diff

[jkrems]

Does removal of array support complicate its future addition? It would require user-agent sniffing (or waiting a long time) to use array syntax if past versions wouldn't be able to accept them.

For node we currently plan to support synchronous arrays only, e.g. we'll never try to fetch more than one of the resolutions. That way a "protocol whitelist" is enough to make the decision while still allowing for future std: modules or more complex guards.

[domenic]

Does removal of array support complicate its future addition? It would require user-agent sniffing (or waiting a long time) to use array syntax if past versions wouldn't be able to accept them.

Or feature detection, using the error event to detect parse errors.

However, I find it unlikely that we'll add the array syntax back at any point, given the implementation complexities that come with it, and the standards quagmire around built-in modules. I currently have no plans to do so.

For node we currently plan to support synchronous arrays only, e.g. we'll never try to fetch more than one of the resolutions. That way a "protocol whitelist" is enough to make the decision while still allowing for future std: modules or more complex guards.

I would suggest following the spec and not supporting arrays at all.

[jkrems]

I would suggest following the spec and not supporting arrays at all.

To clarify: We're not literally implementing import maps (at least not yet). Unfortunately there are use cases that require declarative switching between implementations so we'll have to implement something in node and likely rather sooner than later or the ecosystem will find a way™.

[domenic]

I finished this off, and will merge it now in the interest of having an up-to-date explainer. Review still appreciated.