Supporting non-fetch-scheme URLs

[guybedford]

(reposted as GitHub seems to be somewhat flaky today..)

Currently non-fetch-scheme URLs are silently ignored in the implementation. I feel quite strongly that this is hostile to future protocol development on the web, for example the dat:// and ipfs:// protocols may wish to use import maps in future.

For example:

{
  "import": {
    "asdf": "dat://asdfgh"
  },
  "scopes": {
    "dat://asdfgh": {...}
  }
}

is rewritten into:

{
  "import": {
    "asdf": []
  },
  "scopes": {
  }
}

I don't see why we can't have the URL parser just do its normal resolution for these kinds of URLs, allowing the implementation to be easily compatible with future protocol developments on the web.

I believe @annevk expressed some concern around these use cases in a related thread before. I'm sure many others share these concerns as well.

[domenic]

Well, on the web these aren't supported, so they won't be in the import maps spec. If they become fetch schemes on the web, then they will be supported by import maps automatically.

[domenic]

Closing, since I don't think there's any potential action here; dropping from the parsing step just makes the warning appear earlier instead of causing a fallback or other fetch failure later, i.e. the OP basically is just requesting to make the type of error more user-unfriendly, which is not desirable. But happy to continue discussing if that's not clear.

[guybedford]

I just don't understand why the restriction is necessary or useful. But sure, we can pass this over to future protocol developers to fix this problem.

[domenic]

It gives better, quicker error messages with no round-trip to the network stack, allowing developers to more easily see that they have supplied no URLs that are fetchable to the import maps architecture, instead of having the import maps architecture say "everything's fine" only for the network stack to be the one who delivers the bad news to the application.

This isn't pushing the problem onto "future protocol developers". This is just proper layering. If in the future a new fetchable scheme gets added to the web, it automatically flows into the import maps spec, with no problems and no edits to the import map spec. (And no changes to the import map implementations, assuming they are properly integrated with a fetch implementation---which the reference implementation is not, of course, since it's not part of a browser.)

[guybedford]

This is just proper layering. If in the future a new fetchable scheme gets added to the web, it automatically flows into the import maps spec, with no problems and no edits to the import map spec. (And no changes to the import map implementations, assuming they are properly integrated with a fetch implementation---which the reference implementation is not, of course, since it's not part of a browser.)

Great

[annevk]

FWIW, that makes sense to me. I think my main quibble was with the claim that there wouldn't be new schemes. But a standard that builds upon "fetch schemes" and defers to "fetch" will indeed automatically gain support for new schemes that can be fetched in some way and turned into a response.