v133 · miscellaneous

Multiple 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 need

concepts

  1. Multiple Import Maps

    Multiple import maps allowed per document; later maps extend earlier ones. Lets multi-team builds compose maps without merging at build-time.

  2. Microfrontend compose

    Team Shell and Team Checkout ship independent import maps; both resolve live in-page via import.meta.resolve. The multi-team-build use case from the chromestatus entry.

  3. Incremental load timeline

    The motivating perf use case: ship a tiny boot map, then add route maps as routes load. Walk the timeline and compare with the legacy single-map blocker.

  4. Import map conflict resolver

    Edit two import maps, click Resolve — see which specifiers conflict (same key in both maps), which map wins (first wins), and the merged result as a copy-ready JSON block.

  5. Environment override

    A base map ships with the HTML; a second override map swaps api/client, analytics, and router to dev, staging, or test endpoints. Switch environments to watch the merged resolution update live and type any specifier to see exactly which URL it resolves to — and whether the base or override map wins.

why it shipped

Import maps in their current form provide multiple benefits to web developers. They enable them to avoid cache invalidation cascades, and to be able to work with more ergonomic bare module identifiers, mapping them to URLs in a convenient way, without worrying about versions when importing.

references