WICG / import-maps

How to control the behavior of JavaScript imports
https://html.spec.whatwg.org/multipage/webappapis.html#import-maps
Other
2.68k stars 69 forks source link

Discussion: relative urls within a scope #148

Closed joeldenning closed 5 years ago

joeldenning commented 5 years ago

Scenario

Assume you are at http://example.com/index.html and a module under the /js/ scope imports module a. With the following import map, what url does module a resolve to?

{
  "scopes": {
    "/js/": {
      "a": "./a.js"
    }
  }
}

Option 1 - relative to the scope

The a module would be downloaded from http://example.com/js/a.js

Option 2 - relative to the page

The a module would be downloaded from http://example.com/a.js

Related / previous work

See related https://github.com/WICG/import-maps/issues/29 and https://github.com/WICG/import-maps/pull/30, which seem to indicate that Option 1 is the correct option. However, then consider this commit which removed that clarification, and this test in the reference implementation which seems to contradict what was previously decided on.

In the test, lodash-dot is being resolved to https://example.com/app/node_modules_2/lodash-es/lodash.js (Option 2) instead of to https://example.com/app/js/node_modules_2/lodash-es/lodash.js (Option 1).

Clarification needed

I propose we clarify this section of the spec to specifically discuss relative urls within an import map scope. I'm just not sure whether Option 1 or Option 2 should be in it.

domenic commented 5 years ago

The intention here is option 2. All URLs on the right-hand side are URLs, and interpreted relative to the base URL of the import map (for inline import maps, that is the same as the URL of the page).

This changed with the switch from package name maps (which the issues you mention were about) to import maps (which is the rewrite commit you reference).

The spec and reference implementation are clear on this, but I'm happy to update the explainer.

joeldenning commented 5 years ago

👍 thanks for the clarification, I must have missed that section in the spec. Your change to the readme clarifies it well.