Problem/Motivation
Importmaps allow a browser to resolve naked ES imports.
e.g.
import React from 'react';
Ordinarily a browser doesn't understand how to resolve that, but with an import map it can.
However, you can only have one <script type="importmap"> element on a page, so therefore it makes sense to have an API in core to support this. In addition you cannot dynamically update this, so e.g. things like Ajax responses cannot add new importmaps. As a result we need to declare all possible import maps on the page.
Adding this API will allow us to do more interesting things with JavaScript. E.g. consider two modules that rely on a JavaScript library. If both of them bundle the same library into their code, there will be two instances of this in the page.
A concrete need for this is for the React module and the Gutenberg and Decoupled layout builder modules. Both of them need React loaded into the page.
Without importmaps, both of them will need to hard-code a reference to the URL of the bundled react libraries provided by the React module.
With importmaps, both of them can configure their bundler (Vite/Webpack) to mark React as external - this will result in the bundler leaving import React from 'react' in the bundled code.
Then the React module could specify an importmap via this new API and Drupal would take care of emitting an <script type="importmap"> into the page.
Proposed resolution
Add an API to core for importmaps. Base this off the Importmaps contrib module.
At present the importmaps module uses hook_page_top to unconditionally add the <script type="importmap"> tag to the page.
Remaining tasks
Agree we want to do this.
Adapt the code in importmaps (e.g. YML discovery, plugin manager).
User interface changes
API changes
New plugin manager and YML plugin discovery for importmaps