What problem are you trying to solve?

Currently, the syntax to include an import map is very much tied to HTML. This means that:

• Any script adding an import map needs to handle HTML with DOM methods, which violates separation of concerns
• Any build tool generating import maps needs to hook into HTML templating.
• Separate importing contexts need to be supported separately, with additional spec/implementation work, e.g.:
  • Web workers: Supporting import maps in worker environments #8173 Web Workers importmap field #11002 Support import maps in workers #10858
  • Worklets
  • Feature request: import(url, {importmap: {...}}) #8877
  • Import maps cannot be used with HTTP Link rel=modulepreload  #9274
  • SVG
  • CSS (why? see Declarative CSS Modules and Declarative Shadow DOM adoptedstylesheets attribute #10673)
  • Realms

What solutions exist today?

• Authors currently work around the lack of external import maps by generating a JS file that uses DOM methods to inject the import map. This is fragile, awkward, and depends on an HTML DOM being available in the current context
• Add external import maps #8355 would solve some of the issues, but not even the majority, and at this point seems like minor syntactic sugar over the current DOM-based handling.

How would you solve it?

We already have the Link HTTP header to link to external resources, essentially what <link> does, but through HTTP. All we'd need to do is add a rel=importmap and well, actually handle it 😀

Why an HTTP header?

• Most webhosts provide means for setting HTTP headers en masse, in a much more lightweight way than dealing with HTML templating. Authors use tooling to generate their importmap.json, set the header, and can move on and forget about it. Down the line, webhosts could even handle it automatically, freeing authors entirely from managing or including import maps
• Not every web resource that fetches subresources includes an HTML document or has access to HTML DOM, but by design they all have HTTP headers, so a header-based approach solves it for good, for every possible type of resource.
• No ordering effects of the flavor "whoops, my module loaded before my import map, what to do?". Nothing is available sooner!
• Given that specifiers are essentially an abstraction over URLs, handling the mapping via HTTP does seem to be a more architecturally coherent solution.
• I believe (?) supporting this would also require supporting <link rel=importmap>, so we feed two birds with one scone and get external import maps in HTML as well (albeit with worse syntax than <script type=importmap src>)

Another solution could be to introduce a new header, e.g. Import-Map that works similarly to Link, but I cannot come up with compelling arguments for that over the Link approach.

Anything else?

No response