A full spec is still under development, and will be informed by this work. In addition to the explainer, the following documents are providing guidance to our implementation:
Proto-spec, including more detailed semantics for acquiring import maps
We also have an implementation design doc.
We've filed a TAG review request.
This intent only covers a subset of import maps features:
applied to module script specifiers that appear in:
import statements in module scripts, and
dynamic import() in (module or classic) scripts.
And does NOT include the following:
Fallback involving non-builtin modules (e.g. fallback from HTTPS to another HTTPS URL)
<script> elements' src attribute (even when type="module")
Other non-script contexts, like workers
(This roughly corresponds to cover the first two or three items and to intentionally exclude the last item in the implementation staging in the WICG explainer.)
Import maps enable built-in modules. So far we have avoided speccing and shipping any built-in modules, in large part because they have disadvantages compared to built-in globals. Import maps is an attempt to address these disadvantages.
Concretely, while globals can be polyfilled or virtualized, without import maps, modules cannot be. See more examples in the explainer, for polyfills and for virtualization. Without import maps, the web will likely continue to need to expose features through global variables forever.
Import maps fill the gap between the web platform and other JS modules implementations by allowing the mapping of bare specifiers (e.g. import $ from "jquery"). Web developers used to Node.js, webpack, TypeScript, or other environments expect this capability, but until import maps the web platform would always throw an exception for such imports. Without import maps, developers are generally forced to transpile, i.e. not use the native module system. More background and examples in the explainer.
Interoperability and Compatibility
This Intent tries to take and implement a subset that is not directly affected by the ongoing spec issues, but the structure of the implementation will be different from the structure of the current proposed spec, which causes some minor behavior differences from the current proposed spec.
See Diffs from Full Import Maps Spec Proposal section for details.
None, because this proposal doesn't change existing web pages without import maps. Indeed, it provides a mechanism for polyfilling effectively, i.e. improving compatibility.
This API should help Chrome maintain good performance, as part of a larger program to encourage the use of more granular modules (which can be performance-advantageous over large blocks of bundled script), and also to enable built-in modules, which can be loaded lazily instead of bloating each context.
This feature is specifically designed to improve the activation of built-in modules, allowing web developers to take advantage of them even in browsers without import maps or built-in module support. (See example.)
For the non built-in module use cases, polyfills like the excellent es-module-shims will definitely be helpful.
Additionally, tooling like the various bundlers or package managers will likely want to interact with import maps, either consuming or outputting them. We will be doing outreach during the implementation, once they have something they are able to test behind a flag.
One concern that has been raised during specification development is ensuring that warnings get triggered for various problems with the map (spec issue #80). We will be working to specify and implement 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.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Is this feature fully tested by web-platform-tests?
Planning to add WPT tests, as well as importing and adapting tests from the reference implementation:
Link to entry on the feature dashboard
Requesting approval to ship?
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e2e90777-914c-4038-9300-c891936a348a%40chromium.org.