Intent to Ship: import maps (inline only)
Domenic Denicola
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
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
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
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.
Daniel Bratell
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.
