Scope finding algorithm: Top-level scope's prefix?

[nyaxt]

When finding the applicable scope, what string should we use to do longest prefix matching for the top-level scope?

For example, consider a case given a HTML hosted at http://example.com/baz/app.html:

<script type="packagemap">
{
  "path_prefix": "/foo",
  "packages": {
     "moment": { "main": "src/moment.js" },
  }
}
</script>
<script type=module src="http://example.com/main.js"></script> // should import 'moment' resolve? to which URL?
<script type=module src="http://example.com/foo/main.js"></script> // or would it require this?
<script type=module src="http://example.com/baz/foo/main.js"></script> // or this?
<script type=module src="https://example.com/baz/foo/main.js"></script> // what if html is http page and it references https?
```.

[nyaxt]

I'll proceed with the implementation by requiring the path_prefix to be a valid absolute URL, but given the story is to improve the development time experience, I assume that we want to have some kind of relative URL support.
e.g.) prod URL at https://prod.example.com/app/foo.html, while developing on https://localhost:8000/foo.html

[domenic]

We are working on an answer for how the page URL, package map URL, and module URL all related in #37. Let's be sure to include all these test cases :).

[domenic]

@guybedford, @justinfagnani, is this kind of case covered by the tests yet? What kind of answers do we give?

[guybedford]

For a package map hosted at http://foo.com/lib/map.json and a site at http://example.com/baz/app.html, the base-level path_prefix is resolved to the URL of the package map giving http://foo.com/foo/.

All the cases described then resolve moment to http://foo.com/foo/moment/src/moment.js. That is, the root scope always applies regardless of referrer, while the child scopes themselves resolve relative to the package name map baseURL, to then compare against the referrer. (I did actually test this as well)

Note also that if the path_prefix were foo without the leading /, then the same would apply here but into http://foo.com/lib/foo.

[domenic]

This issue probably still has some relation to the current proposal, but it's hard to extract. Maybe it is covered by #63. Let me close it and we can file a new one that relates to the import maps proposal.