Remote urls are not resolved correctly when passed in as string.

[jespertheend]

import {emit} from "https://deno.land/x/[email protected]/mod.ts";
await emit("https://deno.land/[email protected]/path/mod.ts")

gives

Uncaught Error: Module not found "file:///Users/Jesper/https:/deno.land/[email protected]/path/mod.ts".
    at __wbg_new_651776e932b7e9c7 (https://deno.land/x/[email protected]/lib/emit.generated.js:329:19)
    at <anonymous> (https://deno.land/x/[email protected]/lib/emit_bg.wasm:1:7194705)
    at <anonymous> (https://deno.land/x/[email protected]/lib/emit_bg.wasm:1:2500606)
    at <anonymous> (https://deno.land/x/[email protected]/lib/emit_bg.wasm:1:6371297)
    at <anonymous> (https://deno.land/x/[email protected]/lib/emit_bg.wasm:1:7147137)
    at __wbg_adapter_16 (https://deno.land/x/[email protected]/lib/emit.generated.js:205:6)
    at real (https://deno.land/x/[email protected]/lib/emit.generated.js:189:14)

It took me a bit to figure out I had to pass in the first argument as url to make this work. I think it would be nice if strings behaved the same as urls here.
But maybe I'm missing something and this is not possible, in that case I think it would be a good idea to document this somewhere.

[MierenManz]

Seems to be a bug with the resolve method in std/path Maybe handy to open an issue there aswell?

[jespertheend]

I'm not sure resolve() is intended to be used that way. As there's no way for that function to know whether you intend to resolve a url or a path on your local file system that just happens to start with /https:.

[jcc10]

I would argue that this is kinda fine? Deno web workers work the same way so it's not like there isn't a precedent?

It would definitely be a good quality of life improvement.

[jespertheend]

It's not that I really need this functionality. I'm mostly concerned about new users because it's not immediately clear why urls are failing.