search

drufball / layered-apis

A new standards effort for collaborating on high-level features.
275 stars 12 forks source link

Different fallbacks specified in different places #10

Open domenic opened 6 years ago

domenic commented 6 years ago

Consider the following scenario:

// a.mjs
import "std:infinite-list|https://cdn-a.com/il.mjs";
// b.mjs
import "std:infinite-list|https://cdn-b.com/il.mjs";

Both a.mjs and b.mjs are expressing a dependency on the infinite-list layered API. However, they have specified different fallback URLs. This can be problematic, especially in cases such as custom elements which have global side effects.

Alternate fallback styles, e.g. using package name maps or some other centralized mapping, avoid this problem.

Alternately, we could define a sort of first-fallback-wins rule. In this scenario, assuming std:infinite-list is not implemented, then if b.mjs loads first, a.mjs gets interpreted as if they had written import "https://cdn-b.com/il.mjs". This is kind of strange since that string never appears inside the actual text of a.mjs, but it's not too bad IMO...

littledan commented 6 years ago

+1 to the package-name-maps solution you proposed for expressing fallbacks there.

I like how that solution gives us just one place where package name mapping happens, as opposed to some of it happening in package-name-maps and more of it happening in complex import specifiers.

This fallback solution lets us elegantly meet a set of requirements from TC39 delegates on built-in modules: that built-in modules both support monkey-patching/polyfilling, that the polyfill module be able to access the underlying one, and that there be support for specifically accessing the original built-in module. I think these should all be possible with creative use of path-scoped remapping.