deno_emit
deno_emit copied to clipboard
Remote urls are not resolved correctly when passed in as string.
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.
Seems to be a bug with the resolve
method in std/path
Maybe handy to open an issue there aswell?
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:
.
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.
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.