Intent to Ship: import maps (inline only)

718 views
Skip to first unread message

Domenic Denicola

unread,
Dec 11, 2020, 7:17:57 PM12/11/20
to blink-dev

Contact emails

hiro...@chromium.org, dom...@chromium.org, kou...@chromium.org


Explainer

https://github.com/WICG/import-maps/blob/master/README.md


Specification

https://wicg.github.io/import-maps/

We plan to work on a HTML Standard pull request for this in the near future.


API spec

Yes


Summary

Import maps allows control over what URLs get fetched by JavaScript import statements and import() expressions.


This I2S is for inline <script type="importmap"> only. We additionally want to support external <script type="importmap" src="...">, but will request support for that separately when the implementation is complete and well-tested.


Blink component

Blink>HTML>Script


TAG review

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


TAG review status

Issues addressed


Risks



Interoperability and Compatibility

This feature has had previous discussion with other vendors, with some positive signals. Code that uses bare specifiers will work only in browsers that implement import maps, and will need a polyfill in other browsers; such polyfills do exist.


Import maps have been carefully designed with an eye toward future extensibility in various directions: https://github.com/WICG/import-maps#further-work. We are confident that the portion being shipped can be extended in those directions without compatibility risk.



Gecko: Positive (https://mozilla.github.io/standards-positions/#import-maps)


WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2020-October/031555.html)


Web developers: Strongly positive (https://github.com/WICG/import-maps#community-polyfills-and-tooling) Since the origin trial for this feature, we have been continually getting pings from developers asking when it will ship.


Ergonomics

This API will be used in tandem with the JavaScript module system. A lot of attention has been paid to making the mapping relatively easy to use and ergonomic.


This API should help Chrome maintain good performance, as part of a larger program to allow the use of more granular modules (which can be performance-advantageous over large blocks of bundled script). It also helps with certain performance-positive caching strategies for modules.



Activation

This feature benefits greatly from tooling (to generate and maintain the import map) and polyfills. Fortunately, the community has stepped up to provide both of these: https://github.com/WICG/import-maps#community-polyfills-and-tooling



Security

We have worked to ensure that import maps are strictly less powerful than service workers or first-party scripts in terms of their URL-rewriting capabilities. See also the specification's discussion of these issues: https://wicg.github.io/import-maps/#security-and-privacy



Debuggability

One concern that has been raised during specification development is ensuring that warnings get triggered for various problems with the map. We have implemented such warnings.


Also, full logging information for each import map resolution will be helpful, for example:


* Showing how import maps are parsed (by printing the normalized, parsed import map data structure, to detect whether the provided string is parsed as expected).


* Which key of the import map is used (to debug the matching of import map keys).


* Which value of the import map is used (e.g. why the fallback occurred or didn't occur).


We still need to explore how to expose this, and will work with the DevTools team to figure that out.


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

Yes.


Some tests shown at that link rely on Blink internals.* APIs (and thus show as failing on wpt.fyi even in Chrome). We need to either move them to wpt_internal, or introduce new test-only APIs or WebDriver extensions to support them. We'll be working on that shortly. However, we believe the coverage provided by all the other tests is very high already; the internals.*-using tests were developed as convenient unit tests.


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=848607


Measurement

https://chromestatus.com/metrics/feature/timeline/popularity/2831


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5315286962012160


Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/qYeQFqgFOyA/m/rXJapjMaEAAJ

Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/sEwWEF80T4s/m/Nss9VxM3BAAJ



This intent message was generated by Chrome Platform Status.


yo...@yoav.ws

unread,
Dec 17, 2020, 2:47:47 PM12/17/20
to blink-dev, Domenic Denicola
LGTM1

On Saturday, December 12, 2020 at 1:17:57 AM UTC+1 Domenic Denicola wrote:

Contact emails

hiro...@chromium.org, dom...@chromium.org, kou...@chromium.org


Explainer

https://github.com/WICG/import-maps/blob/master/README.md


Specification

https://wicg.github.io/import-maps/

We plan to work on a HTML Standard pull request for this in the near future.


API spec

Yes


Summary

Import maps allows control over what URLs get fetched by JavaScript import statements and import() expressions.


This I2S is for inline <script type="importmap"> only. We additionally want to support external <script type="importmap" src="...">, but will request support for that separately when the implementation is complete and well-tested.


A tangent, but I'd love to better understand the performance characteristics of an external import map, as that seems like a potential performance foot-grenade.


Blink component

Blink>HTML>Script


TAG review

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


TAG review status

Issues addressed


Risks



Interoperability and Compatibility

This feature has had previous discussion with other vendors, with some positive signals. Code that uses bare specifiers will work only in browsers that implement import maps, and will need a polyfill in other browsers; such polyfills do exist.


Import maps have been carefully designed with an eye toward future extensibility in various directions: https://github.com/WICG/import-maps#further-work. We are confident that the portion being shipped can be extended in those directions without compatibility risk.



Gecko: Positive (https://mozilla.github.io/standards-positions/#import-maps)


WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2020-October/031555.html)

 
The response on that thread seems to be more on the negative side. 


Web developers: Strongly positive (https://github.com/WICG/import-maps#community-polyfills-and-tooling) Since the origin trial for this feature, we have been continually getting pings from developers asking when it will ship.


That's a great signal!
 

Ergonomics

This API will be used in tandem with the JavaScript module system. A lot of attention has been paid to making the mapping relatively easy to use and ergonomic.


This API should help Chrome maintain good performance, as part of a larger program to allow the use of more granular modules (which can be performance-advantageous over large blocks of bundled script). It also helps with certain performance-positive caching strategies for modules.


I'm particularly excited about the impact of mapping on immutable resources (with content-addressed URLs), and the fact that changing such a resource would stop "bubbling" up the dependency tree with maps.
I almost wish this benefit wasn't limited to modules.

Daniel Bratell

unread,
Dec 17, 2020, 2:58:49 PM12/17/20
to yo...@yoav.ws, blink-dev, Domenic Denicola

LGTM2

(as Yoav mentions, there would be no big surprise if there is a demand for client-side remapping functionality for generic resources)

/Daniel

--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f56272b1-78c3-444e-a584-c4fe7fc09e17n%40chromium.org.

Mike West

unread,
Dec 17, 2020, 3:27:28 PM12/17/20
to blink-dev, Daniel Bratell, Domenic Denicola, yo...@yoav.ws
LGTM3.

I'm happy with the way in which the team has dealt with security considerations, in particular the integration with CSP. They've dealt with the potential issues nicely, and I'm happy to see this ship.

-mike
Reply all
Reply to author
Forward
0 new messages