Import map composition implementation

[guybedford]

There has been progress on this in WICG/import-maps#167.

Before releasing v6 it would be worthwhile to see if we should be implementing this approach or not, to avoid the immediate need for a v7 release.

[guybedford]

I just wanted to provide my implementation notes on the approach before I start, based on following the reference implementation PR.

The behaviours expected for import map composition are the following:

• All import maps are fully resolved to their baseURL into absolute URL space. Bare specifiers on the RHS of the map are left in place during this phase.
• Import map composition is applied based on applying the normalization of the RHS in the new map based on the rules of the old map. Bare specifiers on the RHS can be remapped this way.
• During composition resolution, the new map "imports" apply RHS resolution based on only applying the "imports" of the old map.
• During composition resolution, the new map "scopes" apply RHS resolution based on applying any scoping rules that match the scope (as well as "imports"), but excluding any more specific scoping rules. More specific scoping rules of the old map do not cause scope intersections to form.
• When composing resolutions, fallback arrays are expanded into their position in the RHS list.
• Any bare specifiers left over are removed from the fallback list as map validation failure - Non-URL specifier "..." is not allowed to be the target of an import mapping following composition..

//cc @michaelficarra @bakkot I hope the above sounds like a sensible summary of the behaviours. If there are any gaps in the logic do let me know.

[bakkot]

That all looks right, except:

When composing resolutions, fallbacks chain in order, such that the resolution array length is fully monotonic.

Consider merging

{
  "imports": {
    "a": [],
    "b": [],
    "c": ["x"]
  }
}

and

{
  "imports": {
    "y": ["a", "b", "c"]
  }
}

so that the first map already exists and the second is being added on top of it. Then the fallback array for "y" ends up as ["x"], which is shorter than previously. So the length of the fallback array is not necessarily monotonic.

---

Also, a couple of points you didn't mention:

• both the top-level imports and each specific scope which exists in both maps are merged by performing the resolution on the second one as described in your comment, and then adding all of its keys to the first, overriding any which may have been there previously. That is, this implementation uses the "merge-within-scopes" option presented in Merging behavior: should we merge within scopes? WICG/import-maps#153.
• Bare specifiers on the RHS which are present after composition cause an error to be thrown during the composition operation. It's probable this should happen for the very first map on the page as well (treating "add an import map to a page which didn't have one" as "composition an import map into the empty import map"). If that's done, the point about "During import map resolution, any bare specifiers on the RHS only throw when resolved to." will be obviated, because it will be impossible to resolve to a bare specifier.

[guybedford]

Thanks @bakkot for the quick feedback here, that helps a lot.

So the length of the fallback array is not necessarily monotonic.

I've corrected the note on this.

That is, this implementation uses the "merge-within-scopes" option presented in WICG/import-maps#153.

We already implement this merging strategy in SystemJS actually.

Bare specifiers on the RHS which are present after composition cause an error to be thrown during the composition operation.

I've also updated the notes on this point.

[guybedford]

PR created at #2009.

[guybedford]

Released in 6.0.0.