Intent to Prototype: Dynamic import maps

[Yoav Weiss (@Shopify)]

Contact emails

yoav...@chromium.org

Explainer

https://github.com/whatwg/html/pull/10528#issue-2437162429

Specification

https://github.com/whatwg/html/pull/10528

Summary

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 they become a large blocking resource, as the entire map for all possible modules needs to load first. This feature is to enable multiple import maps per document, by merging them in a consistent and deterministic way.

Blink component

Blink>HTML>Modules

Motivation

Import maps in their current form provide multiple benefits to web developers. They enable them to avoid cache invalidation cascades, and to be able to work with more ergonomic bare module identifiers, mapping them to URLs in a convenient way, without worrying about versions when importing. At the same time, the current import map setup suffers from fragility. Only a single import map can be loaded per document, and it can only be loaded before any module script is loaded. Once a single module script is loaded, import maps are disallowed. That creates a situation where developers have to think twice (or more) before using module scripts in situations that may introduce import maps further down in the document. It also means that using import maps can carry a risk unless you’re certain you can control all the module scripts loaded on the page. Beyond that, the fact that import maps have to be loaded before any module means that the map itself acts as a blocking resource to any module functionality. Large SPAs that want to use modules, have to download the map of all potential modules they may need during the app’s lifetime ahead of time.

Initial public proposal

https://github.com/whatwg/html/pull/10528

TAG review

https://github.com/w3ctag/design-reviews/issues/980

TAG review status

Pending

Risks

Interoperability and Compatibility

None

Gecko: No signal

WebKit: No signal

Web developers: Shopify developers would need this in order to use ES modules proper. I haven't yet gathered a signal beyond that.

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Is this feature fully tested by web-platform-tests?

Not yet, but it will be

Flag name on chrome://flags

None

Finch feature name

None for now, but I'd add a flag before shipping.

Non-finch justification

None

Requires code in //chrome?

False

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5121916248260608?gate=5075513421594624

This intent message was generated by Chrome Platform Status.