Coverage report blank when transpiling outside of @web/test-runner

[m1cr0man]

I am attempting to use @web/test-runner in conjunction with an esbuild-based building environment, as per this webapp starter project I have made.

When I run wtr, the resulting coverage report contains no data - the icov.info file is empty and the HTML shows 0/0 items covered.

I have tried configuring esbuild to output source maps both inline and external, to no avail. I also tried adding all my files to the "include" coverageOptions for wtr, but this also had no effect.

Is there a hard requirement on wtr performing the build in order for coverage reports to work? I would prefer to use my own esbuild.js script so that I can ensure I am testing the same code that will end up on the browser in production.

I have picked up from the docs that wtr relies on chromium's instrumentation to produce coverage reports, so I feel I have simply missed part of the setup process either in my tests or my build framework to make it work but I'm not sure what.

[LarsDenBakker]

The coverage should work if the source maps are correct. Often source maps don't link back to the original file correctly for example. Is this something you could double check?

Compiling outside of WTR happens often, for example with TSC: https://github.com/modernweb-dev/example-projects/tree/master/lit-element-ts-tsc

[m1cr0man]

I just compiled with inline and external source maps to check the file paths. In both cases they are correct - however I discovered that only inline source maps are working in dev tools as it seems esbuild is stripping its own //# sourceMappingURL for external maps. I was able to fix this temporarily using its --footer parameter. I will open a bug on their side for that.

Alas, even with inline source maps and correct paths I'm getting no coverage reports. There's nothing to show from the WTR/browser log for the record - no errors or warnings.

[LarsDenBakker]

I tried to run your project, but it's not able to resolve this dependency:

"esbuild-plugin-postcss-literal": "../esbuild-plugin-postcss-literal",

Can you try without any coverageConfig configured? That should match all files.

[m1cr0man]

I tried to run your project, but it's not able to resolve this dependency:

"esbuild-plugin-postcss-literal": "../esbuild-plugin-postcss-literal",

Can you try without any coverageConfig configured? That should match all files.

Ah - sorry about that! I will update it to use the URL to my fork as I'm waiting for a PR to be merged.

I will try without coverageConfig and report back.

[m1cr0man]

I tried to run your project, but it's not able to resolve this dependency:

"esbuild-plugin-postcss-literal": "../esbuild-plugin-postcss-literal",

Can you try without any coverageConfig configured? That should match all files.

I have updated the project to pull the plugin via a git+https URL and changed the source map to inline. I am still not getting any coverage reports though even after removing the coverageConfig 😞

[crisward]

Also having this issue. My plugin outputs the result of esbuild with a svelte plugin

plugins: [ 
    {
      name: 'my-plugin',
      async transform(context) {
        // console.log(context)
        if (context.request.url.match(/^\/tests/)) {
          let filename = "./tests/"+path.basename(context.request.url.replace(/\?.+$/,""))
          // let js = await fs.readFile(filename,"utf8")
          let build = await esbuild.build({
            entryPoints: [filename],
            bundle: true,
            write: false,
            outdir: 'out',
            logLevel: "error",
            sourcemap: "inline",
            sourcesContent: true,
            plugins: [sveltePlugin({
              compileOptions: {css: true}
            })],
          })
          let body = ""
          for (let out of build.outputFiles) {
            if(out.path.endsWith(".js")){
              body+=new TextDecoder().decode(out.contents)
            }
          }
          return { body };
        }
      },
    },
  ],
...

esbuild includes the inline sourcemap as a base64 encoded url. I've checked in the sources panel of chrome and the file structure and files look correct. Wondering if this is being cause by the source map being too big (looks like its including node_modules too).

[Didel]

I know that this issue has been stale for a while. Does one of you remember if you also happened to be using puppeteer while experiencing the empty coverage reports? If so, could this be a possible duplicate of issue #1325 ?

[crisward]

Don't think I'm using puppeteer. Using the chromeLauncher, unless that uses puppeteer (not checked).