Not respecting "inputSourceMap" field from reported coverage data (fails for .gjs - ember-template-imports)

[RathiRohit]

Problem:

With the new support for template imports in ember via ember-template-imports, the component files with inlined templates have .gjs / .gts extensions in source which ultimately transpiles to .js. Istanbul when generating coverage data (in __coverage__), generates this with transpiled file path name (ex. .../component.js) as key. As we're relying on the file path from key value and checking for file existence on disk (with fs.existsSync), these files get skipped from final coverage report as the .js file doesn't really exist in source.

Possible approach to solve this:

Istanbul provides a inputSourceMap field for such files which contains the actual name of underlying source file (ex. .../component.gjs) in the coverage object. ember-cli-code-coverage should respect this inputSourceMap field (whenever available) and use the source mapped filepath instead of relying solely on object key path.

Something on the lines of:

function adjustCoverage(coverage, options) {
  let { root, namespaceMappings, modifyAssetLocation } = options;
  const adjustedCoverage = Object.keys(coverage).reduce((memo, filePath) => {
    let newFilePath = filePath;
    
    // Use mapped source file if available
    if (coverage[filePath].inputSourceMap && coverage[filePath].inputSourceMap.sources.length > 0) {
      newFilePath = path.join(path.dirname(filePath), coverage[filePath].inputSourceMap.sources[0]);
      coverage[newFilePath] = coverage[filePath];
    }
    
    ...
  }, {});
  return adjustedCoverage;
}

To avoid breaking existing workflows, we can make this change behind a config (ex. useSourceMap) which will default to false in the beta release.

Note: The patch shared above works for our normal use case. I am yet to test this thoroughly on different examples. I will be happy to draft a PR in few days if this change looks good to maintainers.

[NullVoxPopuli]

in what scenario do you see the above change breaking existing workflows?

[vstefanovic97]

@RathiRohit I think this might be fixed with latest release 2.1.1, can you try it?