Add basic import maps support

[domenic]

This imports much of the specification from https://wicg.github.io/import-maps/. The main deltas are:

• Does not include support for external import maps, since nobody has implemented these yet. This allows a good deal of simplification, such as by changing "acquiring import maps" + "pending import map script" + "wait for import maps" to a single "import maps allowed" boolean, or integrating "register an import map" into "execute the script element". If a src="" attribute is present on an importmap script element, then an error event is fired.

• Does not include any support for non-Window import maps. The spec draft included stub support for those, with other globals always having an empty import map. This instead ties import maps to Windows directly. If we revisit that in the future we can refactor, but keeping always-empty import maps around on the other globals was clumsy.

• Adds introductory text and examples.

• Adds conformance requirements, both on the script element and on the import map JSON.

• Fixes a few minor specification issues: "parse a URL-like import specifier", the term "import specifier" is a little bit confusing WICG/import-maps#267, Spec doesn't clearly define onerror must be called if import map is added after the 1st module load WICG/import-maps#268, Typo in "A import map is a struct with two items:" WICG/import-maps#270, preparation-time document check should be done first at #register-an-import-map WICG/import-maps#276, Throwing TypeError in resolve a module specifier? WICG/import-maps#277.

Review from @hiroshige-g and @allstarschh appreciated. The new flow in "prepare the script element" and "execute the script element" in particular needs careful review.

• At least two implementers are interested (and none opposed):
  • Chromium has implemented and shipped this
  • Gecko, per Import maps mozilla/standards-positions#146
• Tests are written and can be reviewed and commented upon at: https://github.com/web-platform-tests/wpt/tree/master/import-maps . Maybe should be moved into html/
• Implementation bugs are filed:
  • Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=848607
  • Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1688879
  • Safari: https://bugs.webkit.org/show_bug.cgi?id=220823
  • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): already supported, https://deno.land/manual/linking_to_external_code/import_maps
  • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): Support for Import Maps nodejs/node#49443

(See WHATWG Working Mode: Changes for more details.)

---

/acknowledgements.html ( diff )
/index.html ( diff )
/infrastructure.html ( diff )
/references.html ( diff )
/scripting.html ( diff )
/webappapis.html ( diff )

[zizifn]

I think webkit has feature bug already? https://bugs.webkit.org/show_bug.cgi?id=220823

[allstarschh]

@domenic
Could you explain when the preparation-time document check will fail for import-maps?
As the import map doesn't support external, neither it supports 'async' nor 'defer',
the 'execute the script element' part should be run immediately after 'prepare the script element' for inline import maps, so the 'preparation-time document check' should always succeed.
Should the 'register an import map' be done in 'prepare the script element' ?

[domenic]

I agree the preparation-time document check will never fail for import maps. This is a general programming pattern where you put shared logic inside a shared function (in this case "execute the script element"), even if for some inputs to that function, the logic is not necessary.

I don't think it's a good idea to restructure the specification so that execution of the import map happens during the preparation phase, instead of the execution phase. Even if the results are observably the same, it makes the specification much harder to read and follow.

[hiroshige-g]

Sorry for delay, LGTM. My comments are editorial except for #8075 (comment).

[domenic]

Thanks for the review @hiroshige-g! I think I have addressed everything.

Since there is no big rush, I will wait for co-editor review from @annevk when he gets back, before merging. In the meantime I can do a bit of work on tidying up the tests.

[annevk]

This looks really good. I did not verify all logic, but I did read through it all. I have a couple minor suggestions as a result.

[annevk]

This setup seems like it would allow for races. Shouldn't we call this the moment we see a <script> element that's not an import map or when we see a dynamic import()? At least, I don't think module loading necessarily starts when a <script> element is seen.

[domenic]

I guess you are referring to the period between when you see a <script type=module> in the parser, and the later period (by default, defer timing) where loading starts? I think that's fine, and still deterministic. (Unless you opt in to nondeterminism with async.)

[annevk]

It seems nicer to just build upon element insertion time.

[domenic]

I think I disagree. It feels nicer to centralize the trigger point in the module loading algorithm, and it's nicer that scripts don't have any effect until they start fetching. E.g. it'd be weird if you inserted a script, then removed it before it started fetching, but it still blocked you from using import maps.

[annevk]

But now if you have an async script and then insert an import map it may end up working and depending on the environment it might always work for you, but then break down for a couple of users sometimes.

[domenic]

Yes, there are tradeoffs. But I think this direction is aligned with the general nature of async scripts, which if they depend on or change the environment, are likely to break nondeterministically.

How should we resolve this? To my knowledge all three implementations followed the spec, and it's tested, so we should probably proceed with merging and then open an issue to discuss changing, measuring the compat impact, etc.?

[annevk]

I suppose that's fair. I don't think it's worth tracking this further unless others share my concern. Thanks!

[annevk]

Not going to block on the async race thing, but I'm not a big fan.

Ignoring that this looks great and I'd be happy to see it properly standardized.

[dontcallmedom]

is it intended it got merged into task-source-for-script rather than main?

[domenic]

Nope, sorting that out now over in #8072.