fix: Make lookup result relative to referrer

[nayeemrmn]

Discovered while looking into denoland/deno#15266. The current import-map-relative design could pass as intentional, but that wasn't the way it was being used in cli and I think adjusting to the passed referrer makes more sense.

Also account for conflicts in lookup_imports(). Choose the least specific matching prefix key, rewrite the specifier with it, make sure the rewritten specifier isn't overrided by some other more specific prefix key. e.g.

// import_map.json
{
  "imports": {
    "a/": "https://foo.com/",
    "a/b/": "https://bar.com/"
  }
}

import_map.lookup("https://foo.com/b/c") should match the first entry, rewrite it to "a/b/c", realise that this conflicts with the second entry (it would be remapped to https://bar.com/c) and discard it.

[CLAassistant]

All committers have signed the CLA.

[nayeemrmn]

This (reverse) lookup API doesn't belong in this repo IMO, we should keep the implementation in the LSP. It's non-spec and needs to have opinionated selection logic specific to the application i.e. the import-map-remap diagnostic.

[nayeemrmn]

@dsherret Can this be landed?

[bartlomieju]

Nayeem, I would actually be interested in landing this PR - I want to finally solve that issue in the LSP where you get a completion for a symbol and it doesn't use import map prefix but the full URL. I was thinking we should just remap the specifiers provided from TSC to use import map (if they're eligible) and it appears this API would be perfect for that purpose.

Could we reopen this PR?

[bartlomieju]

@nayeemrmn could you add your example from the PR description as a test?

[bartlomieju]

Wait I'm a little lost here - why isn't it getting remapped by the first entry? There is no other entry that could remap it to something else, since one entry is for foo.com and the other is for bar.com

[nayeemrmn]

If it was successfully reverse-mapped by the first entry, that output would be forward-mapped by the second entry to something that wasn't the original URL, so import_map.resolve(import_map.lookup("https://foo.com/b/c")) == "https://foo.com/b/c" wouldn't hold.

[bartlomieju]

But how would that happen if the first entry can't remap the provided URL?

[nayeemrmn]

Oh you're asking why the reverse-lookup output a/b/c wouldn't get remapped by the first entry. It's because the second entry also matches it and would take precedence because it's more specific. So we have to prevent that reverse-lookup from succeeding.

[bartlomieju]

I "almost" understand this test. Is it a mistake in the test that we're testing https://foo.com/b/c? If it was https://foo.com/a/b I would understand your train of thought but right now I'm lost.

[nayeemrmn]

No https://foo.com/ will be substituted by the a/.

Let's put it like this. If we didn't have this conflict-check, someone has deno.json like:

{
  "imports": {
    "a/": "https://foo.com/",
    "a/b/": "https://bar.com/"
  }
}

and the code

import "https://foo.com/b/c";

the LSP would recommend they abbreviate that to:

import "a/b/c";

What will that resolve to on deno run? Because of the more specific second entry it will be:

import "https://bar.com/c";

which isn't the intended target.

So this PR precisely detects those conflicts.