Intent to Ship: Multiple 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

TAG review

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

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

This feature changes the existing behavior of import maps, but does so in a backwards compatible way. Sites that have working import maps right now will continue to work. The main compatibility risk may come from sites with import maps that aren't working today (either defined after module loads or multiple of them) that would start working after this feature ships. As such maps are currently throwing errors, I wouldn't expect them to be common in functioning sites, and there's even a chance that this change will fix such sites.

One thing to note is that we haven't defined a non-destructive way to feature-detect this change. I believe this is fine, as (similar to JS language features) sites would need to use UA version sniffing to know if they can deliver multiple (smaller) import maps or a single large one.

In terms of interop risk, WebKit has expressed a positive position, and I'm planning to implement the feature there as well.

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1058)

WebKit: Support (https://github.com/WebKit/standards-positions/issues/381)

Web developers: Positive
Shopify is interested in seeing this ship.
We also have 6 positive reactions on https://github.com/whatwg/html/pull/10528 and an LGTM from Guy Bedford, who authored the relevant polyfill.

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

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

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

Yes

https://wpt.fyi/results/import-maps/multiple-import-maps?label=experimental&label=master&aligned https://wpt.fyi/results/import-maps/not-overridden?label=master&label=experimental&aligned

Flag name on about://flags

None

Finch feature name

MultipleImportMaps

Requires code in //chrome?

False

Estimated milestones

Shipping on desktop	133
Shipping on Android	133
Shipping on WebView	133

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

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

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJrxQj19LattoOyE3Af5dn%3D50UD9ecpHZWjVZ5-GrMr9w%40mail.gmail.com

This intent message was generated by Chrome Platform Status.

[Alex Russell]

This feels like a natural fix to a critically under-specified feature.

In future, I'd like to see the TAG push back on things like Import Maps and Speculation Rules that use `<script type="...">` as a semantic black box. These features need to:

• Compose consistently, or at least sanely (as this Intent proposes)
• Expose mutation events that aren't just "some text content changed"
• Provide proper DOM traversal and manipulation APIs
• Generally be expressible in ways that aren't just inline JSON blobs

It's bad enough that we are still awash in `<script type="application/ld+json">` as barnacle on HTML semantics, but we shouldn't keep adding to the damage.

Best,

Alex

[Domenic Denicola]

With my HTML editor hat on, I disagree with Alex's characterization of this feature as under-specified, as well as his specific technical points of feedback. I encourage him to raise them on the whatwg/html repository, ideally with a focus on web developer needs and use cases that his preferred APIs would enable that are not possible today.

With my API owner hat on, LGTM1!

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/db5e53f9-9abf-49a0-a0bd-4b7be197c527n%40chromium.org.

[Jeffrey Yasskin]

On Wed, Nov 20, 2024 at 9:25 AM Alex Russell <sligh...@chromium.org> wrote:

In future, I'd like to see the TAG push back on things like Import Maps and Speculation Rules that use `<script type="...">` as a semantic black box. These features need to:

• Compose consistently, or at least sanely (as this Intent proposes)
• Expose mutation events that aren't just "some text content changed"
• Provide proper DOM traversal and manipulation APIs
• Generally be expressible in ways that aren't just inline JSON blobs

It's bad enough that we are still awash in `<script type="application/ld+json">` as barnacle on HTML semantics, but we shouldn't keep adding to the damage.

There's an interesting question here, about what design patterns new kinds of structured metadata should follow, but the TAG's not likely to remember to answer that question if the only record is a comment in a Blink I2S. Can you propose a design principle, if you think there is one here? Note that we're likely to listen to domain experts like Domenic, but we also have been uncomfortable in the past with using `<script type=...>` to wrap data that could have been embedded in another element that matched its semantics better.

Jeffrey

[Mike Taylor]

LGTM2

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-d6B_C0E9y-0wDmNSjY%2B%3DVw6RO9L9rrmyvrY5CfSxb7w%40mail.gmail.com.

[Chris Harrelson]

LGTM3

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b5151ff9-7080-489a-8b8d-a7029886717b%40chromium.org.