My monorepo coverage broke due to relative paths too.

If it helps I solved the issue by providing projectRoot which points the root of the monorepo in the Jest config:

// server/jest.config.js
coverageReporters: [['lcov', { projectRoot: '..' }]],

Paths should be relative IMHO.

I'm currently user of karma-coverage-istanbul-reporter that still uses an older version of istanbuljs, which does have absolute paths.
We cache the results of the tests if the sources didn't change. And if the tests run again, we hit the cache and have the coverage reports back from a previous build.
This report now contains absolute paths, but is not run in the same project directory. Thus the paths are now wrong since they are not relative.
Then our SonarQube analysis fails because it can rightfully not resolve the paths.

So I think relative paths are the better default.
I would fix it exactly as @MartinNuc described if necessary.

@sebastianhaeni what @MartinNuc describes is the fix I put in jest to support reporter configuration.

For me it seems like the lcov tracefile format was defined by the Linux Test Project (http://ltp.sourceforge.net/coverage/lcov/geninfo.1.php), if that is not the original source, please correct me.

There it is defined, that source files should be referenced by absolute paths:

SF:<absolute path to the source file>

Even if relative paths are more flexible, IMHO for compatibility reasons the default format should therefore be absolute paths. Other tools might depend on this, see for example Webstorm/WEB-46615, sonarcloud.io karma-runner/karma-coverage#415.

Note that in karma-coverage, unfortunately the fileformat change (absolute -> relative paths) was introduced in a patch version (2.0.2), therefore possibly in violation with semantic versioning, as it is not backwards compatible.

In istanbuljs/nyc#1277 it was suggested that instead of adding more options

a separate lcovabsolute reporter

should be introduced (which another user created an npm package for). However, from my point of view it would make more sense to use the absolute format by default, if the original format definition states that absolute paths should be used, adding an lcovrelative reporter for other use cases (possibly included in instanbul-reports?).

Also #532 could possibly at least allow both relative and absolute paths to be used, without creating an additional reporter.

Furthermore it seems that absolute paths are currently not supported by lcov/lcovonly, even if projectRoot is configured differently, e.g. if "/" is supplied, the path will still be relative, the empty string or null will result in the current directory being used as projectRoot.

Alternatively all depending projects would have to detect, whether relative paths are used and have to be made compatible. Either way I think there are / will be some breaking changes for developers.

I totally agree that if a standard format exists, it should be followed. This is causing issues for the Code Climate coverage tool, too.