Start on a new reference implementation

[domenic]

So far this includes the type-level schema validation and normalization logic. No domain-level validation is in place yet (i.e. checks on the contents of the strings involved; see #63).

[domenic]

TODO: probably should normalize all right-hand sides into arrays (sometimes one-element arrays).

[domenic]

The parser is much further along. It fully validates and normalizes the "specifier map" structure.

It it missing validation and normalization of the "scopes" structure, i.e. normalizing the keys as URLs.

[domenic]

OK. Parser done, I am pretty sure. Going home for the day. Drive-by reviews appreciated, although given that this implementation is in service of the spec, understand that I might not take all advice on coding style or project setup.

I'll merge this in tomorrow or Thursday, and move on to the resolution algorithm. After that, time to translate into a more formal spec.

[guybedford]

Looks like a great start.

Main thing I think is I would still prefer explicit type errors to help authorship of these maps instead of silent failure.

I'm not sure why we're restricting to fetch scheme URLs on the map, I suppose I prefer a concept of URL schemes being extensible and not some centralized list.

[guybedford]

Out of interest, why can't both of the above branches just be represented by:

try {
  return new URL(string, baseURL);
}
catch () {
  return null;
}

I thought absolute URL parsing in new URL(absoluteURL, referrerURL) was independent of the referrer?

[domenic]

I find using try/catch for non-exceptional cases unfortunate, so I created this little wrapper. See whatwg/url#372.

[guybedford]

It was somewhat nitpicking the implementation details, but the suggestion was that:

if (string.startsWith('./') || string.startsWith('../') || string.startsWith('/')) {
  return new URL(string, baseURL);
}
const url = tryURLParse(string);
if (url === null) {
  return null;
}
if (hasFetchScheme(url)) {
  return url;
}
return null;

could be replaced with the implementation-equivalent:

const url = tryURLParse(string, baseURL);
if (url && hasFetchScheme(url)) {
  return url;
}
return null;

Although this is personal preference, and conceptual clarity should dominate too.

[guybedford]

I worry a little about this inhibiting experimentation with other protocols... what is the reason for this restriction?

[domenic]

Since it ignores them, I don't think it will inhibit experimentation. (See #80.) It's just that the initial spec will throw them away since they are unfetchable.

I don't think this will be observable except through side channels. E.g. you would probably see something in the dev console/network panel that fetches and fails if we kept them, whereas when we ignore them, you wouldn't see that. But since the fetch is always a failure anyway for non-fetch schemes, the result observable to the page would be the same.

[guybedford]

Since it ignores them, I don't think it will inhibit experimentation. (See #80.) It's just that the initial spec will throw them away since they are unfetchable.

Right, but what happens if a browser implements a new protocol? Are fetch schemes extensible to support this?

[guybedford]

Say Node.js might want to implement its own internal schemes - if it were to implement package maps, it would then be "spec invalid"?

New protocols should not hit frictions in places like this.

The idea of locking down protocols just makes me weary in general, and I just don't understand what benefits we get for that.

[domenic]

Yes, I anticipate that Node.js will not implement the browser spec for import maps exactly, precisely because it takes a dependency on browser concepts like "fetch schemes".

[guybedford]

Can we not throw on invalid right hand side types?

[guybedford]

I would prefer to throw for empty string maps and scopes.

[domenic]

Empty string scopes seem useful. If you disagree please open a separate issue. For empty string specifier keys, and other cases where you'd prefer to throw, let's discuss in #80.

[guybedford]

I'd still prefer to be strict and throw errors for invalid cases.