What problem are you trying to solve and what solutions exist today?

Currently, reading and writing import maps on the page requires DOM methods, which is an unfortunate coupling, since fundamentally import maps have nothing to do with HTML.

Additionally, DOM methods only allow authors to read individual import maps. Although there is an algorithm to merge import maps and produce the import map of the page itself, authors have no way to access the result, short of re-implementing it.

There is import.meta.resolve() but that requires a module scope. Additionally, it does not actually get you an import map but a finished resolution.

How would you solve it?

Some sort of API to get:

• Get existing import maps
• Get computed global import map
• Add new import map

Possibly:

• An ImportMap interface to represent import maps after normalization
• An ImportMaps extends ObservableArray<ImportMap> interface (rel: Make ObservableArray "subclassable" webidl#1342) that adds a computed property that returns the computed import map of the array as a frozen, memoized ImportMap object
• A global importMaps property that is an ImportMaps instance. Later, other resources could have similar arrays hanging on different objects, e.g. import.meta.importMaps, document.importMaps etc.

These are both very thin wrappers over the current DOM-based API and easily polyfillable, but can be adopted by non-DOM environments such as JS runtimes and workers. Being synchronous prevents some of the issues with import ... with { type: "importmap" }

TBD:

• Does adding an import map via this API add a new DOM element? I vote no, since the whole point is decoupling from the DOM. DOM would become one input mechanism, but not the only one.
• Assuming the answer to the above is no, how do DOM import maps combine with import maps specified via this API? Presumably once an import map is parsed and merged into the global import map, it gets added to the array regardless of where it comes from.