Supporting bare addresses

[guybedford]

I'm glad to see that recursive resolution is no longer being provided.

Given this, should we consider supporting bare addresses? This would allow:

{
  "imports": {
    "x": "./x.js"
  }
}

to be equivalent to:

{
  "imports": {
    "x": "x.js"
  }
}

I'd be glad to put a PR together as well if this would be useful.

[domenic]

Hmm. I think you're right this is possible.

I lean toward the conservativism of requiring the ./ prefix, and vaguely it feels like there might be a rule of "when using URLs in module-ey contexts, use the ./ prefix". But my reasoning here isn't very strong.

I'd be OK with changing this, but I wouldn't rush into it. Does anyone else have an opinion?

[zenparsing]

Do you think some users would expect recursive application to work if they see a bare import as the map target?

[domenic]

That's a good question. My initial instinct is it would depend on what else was nearby in the import map. If it were a bunch of URL-ey things they might see a "bare" relative URL as what it is (i.e. a URL). Similarly, the OP has a .js extension, which helps indicate that it'd be a URL-ey thing. But if it were a small import map without obvious extensions, then it might be more confusing...

[eliasvasylenko]

I think these arguments #80 apply here too; soft failures should be preferred over permissive reinterpretation, just as they should be preferred over hard failures.

The probability that people will want to prescribe new meaning to bare addresses in the future may seem low, but it's surely non-zero, and I don't think supporting them in this way actually buys anything in the meantime.

[rictic]

Given the goal to allow a specifier to resolve to a built-in module, it would be better to require ./. Taking the example from the readme:

{
  "imports": {
    "@std/kv-storage": [
      "@std/kv-storage",
      "/node_modules/kvs-polyfill/index.mjs"
    ]
  }
}

If a mapping to x.js should resolve to ./x.js, then the mapping to @std/kv-storage could be read as resolving to ./@std/kv-storage.

[domenic]

@rictic your argument makes sense, but to me it argues for a simpler solution: use URL-like built-in module specifiers, like std:kv-storage, instead of bare-specifier-like ones, like @std/kv-storage. Then the addresses (i.e. the right hand sides) are always URLs, and we can have confidence that we would interpret x.js or @std/kv-storage the same as ./x.js or ./@std/kv-storage.

[mikesamuel]

Banning adjacent // in paths would allow you to use //@std/kv-storage to move the std out of the path component without introducing something that looks like a scheme or a Windows volume.

I know that module specifiers aren't URLs and import: URLs aren't hierarchical, but the less work code that produces and mixes&matches import maps can do with existing URL libraries, the easier it will be to adopt them.

[domenic]

Now that we have a pretty solid foundation, I'd be happy to take a PR for the spec/tests adding support for this.

[guybedford]

I was just looking at the spec at https://wicg.github.io/import-maps/#sort-and-normalize-a-specifier-map, and according to the outline there this is already supported I believe since there are no explicit checks for ./ anymore.

I think we can close this then?

[domenic]

I think we'd need tests at the very least. Also, this may change if #137 happens; that proposes that the right-hand side no longer be URLs, but instead module specifiers.

[domenic]

I'll consider this blocked on multiple import maps and the work on #137. Since multiple import maps are no longer part of the MVP, moving the milestone.