Dynamic import maps

[yoavweiss]

こんにちは TAG-さん!

I'm requesting a TAG review of Dynamic import maps.

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 the become a large blocking resource, as the entire map for all possible modules needs to load first.

This proposal is to enable multiple import maps per document, by merging them in a consistent and deterministic way.

• Explainer¹ (minimally containing user needs and example code): url
• Specification URL: spec url
• Tests: Not yet
• User research: N/A
• Security and Privacy self-review²: url
• GitHub repo: url
• Primary contacts (and their relationship to the specification):
  • Yoav Weiss (@yoavweiss), Shopify
• Organization(s)/project(s) driving the specification: Shopify
• Key pieces of existing multi-stakeholder (e.g. developers, implementers, civil society) support, review or discussion of this specification
• Key pieces of multi-implementer support:
  • Chromium comments: Intent to Prototype
  • Mozilla comments: Dynamic import maps mozilla/standards-positions#1058
  • WebKit comments: Dynamic Import Maps WebKit/standards-positions#381
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5121916248260608

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: Hoping to ship by EoY
• The group where the work on this specification is currently being done: HTML
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): HTML
• Major unresolved issues with or opposition to this specification: None AFAIK
• This work is being funded by: Shopify

[LeaVerou]

This is very exciting stuff! 😍 ¹

As a very initial comment, could you please add usage examples to the explainer (or a move it to actual, separate explainer) that show what design is actually being proposed? We simply don't have the bandwidth to be wading through pull request diffs to hunt this information down, and I really wouldn't want something like this to fall off our radar because of this.

Footnotes

1. A comment to the problem being solved; I have not seen the proposed design because looking for it exceeded the time I had to allocate… ↩

[yoavweiss]

Thanks!!

I added a usage examples section to the explainer.

We simply don't have the bandwidth to be wading through pull request diffs to hunt this information down

Yup, totally understandable! Let me know if the above helps, or if you'd like me to pull the explainer to its own doc. (The current form felt more "discoverable", but happy to move it if that helps)