deno coverage doesn't use import maps and is unable to retrieve files

[andreas-wagner]

Hi, my files are on gitlab.com, which doesn't provide proper headers and as such is unusable with Deno.

Because of this I have written a small software layer and am using import maps so that cache and lsp are able to get the files, which works fine.

Since coverage doesn't do that, it is unable to retrieve the files and build the coverage.

Don't get me wrong, the files are there, but in <cache>/deps/http/127.0.0.1_PORT3124 instead of <cache>/deps/https/gitlab.com.

"Easy" fix would be to have import maps on the coverage subcommand as well.

[lucacasonato]

cc @caspervonb

[caspervonb]

Will look into it.

[lowlighter]

Here's a minimal reproduction if needed:

import type { LevelName } from "std/log/levels.ts"
Deno.test("test", () => {})

{
  "imports":{
    "std/":"https://raw.githubusercontent.com/denoland/deno_std/69f3d67cb2119e948c91fc471df9d4a0886523a3/"
  }
}

deno test --import-map imports.json --coverage=coverage test.ts
# test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out (77ms)

deno coverage coverage
# error: Relative import path "std/log/levels.ts" not prefixed with / or ./ or ../ from "file:///test.ts"

deno --version
# deno 1.12.1 (release, x86_64-pc-windows-msvc)
# v8 9.2.230.14
# typescript 4.3.5

[caspervonb]

Here's a minimal reproduction if needed:

import type { LevelName } from "std/log/levels.ts"
Deno.test("test", () => {})

{
 "imports":{
   "std/":"https://raw.githubusercontent.com/denoland/deno_std/69f3d67cb2119e948c91fc471df9d4a0886523a3/"
 }
}

deno test --import-map imports.json --coverage=coverage test.ts
# test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out (77ms)

deno coverage coverage
# error: Relative import path "std/log/levels.ts" not prefixed with / or ./ or ../ from "file:///test.ts"

deno --version
# deno 1.12.1 (release, x86_64-pc-windows-msvc)
# v8 9.2.230.14
# typescript 4.3.5

Thanks @lowlighter, appreciate it.

[bartlomieju]

I tried provided reproduction and it appears it was fixed by #13324