Closed Jamesernator closed 2 years ago
Thinking about this, I think a processing model would work something like this:
<script type="importmap">
map is present this is the default import map used by all modules that don't have an associated import mapThe actual "exports"
idea would itself be layered on top of this to provide a better way for authoring multiple import maps (as combined urls would be rather unpleasant to author).
I believe this violates the design principle at https://github.com/WICG/import-maps#scope
It's not clear to me how the design of:
They are not meant to be composed, but instead produced by a human or tool with a holistic view of your web application
Is compatible with any multiple import map support, and if there's only one I don't see how
produced by a human
Is in any way viable without delegation to other import maps. Even with a small number of modules it quickly becomes unviable to maintain by hand.
Note that the user under my suggestion user still has the choice to use their own import map to load the remote package if they want. It's just that it gives the user the freedom to delegate to packages (which may even be author controlled, as is the case with mine).
Is compatible with any multiple import map support, and if there's only one I don't see how
The case we've been told of is when multiple tools are producing the import maps (e.g. JS bundler + CSS bundler; or, a JS bundler for packages and a separate hash-rewriter), or when a tool is producing half the import map (e.g. the node_modules portion) and the developer is hand-editing the other half (e.g. for nicer aliases for common app-wide utilities).
Is in any way viable without delegation to other import maps. Even with a small number of modules it quickly becomes unviable to maintain by hand.
In general I don't think maintaining package mappings is viable for humans; that is best done by tools. Instead it's bespoke per-app mappings that might be hand-maintained.
Currently we can only load a single import map, for code that is structured as packages this requires tooling to generate import maps, this is especially complicated for CDNs that may wish to collapse modules into single files without breaking people's import maps.
This problem is already known and has some suggestions but I would like to propose another potential solution that allows composition of import maps and importantly allows packages to be more independent.
In particular what I propose is the ability to slightly extend import maps to themselves be targets of imports, acting as a package descriptor of sorts. This idea is inspired by
package.json
in Node.js, but rather than searching up the "file system" (or parent urls) for apackage.json
, inside the import map we would directly point to the "import map".The general idea (however some bikeshedding would be needed on the details) is that we would extend the import map to have some kind of "exports" field, consumers of the package could then put a reference to the imported package into their own import map.
As an example of how this would work consider the following example: