Istanbul/coverage reporter generate LCOV file with relative path for SF parameter instead of absolute path #104
Description
We are using Istanbul with Karma to generate a javascript code coverage report. We are using "lcovonly" option for the reporter type.
At present, the file generated by Karma/Istanbul contains a relative path for the SF parameter of lcov.info while it must be an absolute path. (see http://ltp.sourceforge.net/coverage/lcov/geninfo.1.php)
This is causing problems when we try to read this lcov file with sonar javascript plugin because the source files are not found.
We finally end to "patch" some source files of istanbul in order to fix this problem for lcovonly, but I think this should be done for lcov also.
What modifications ?
- /usr/lib/node_modules/karma-coverage/node_modules/istanbul/lib/report/lcov.js
29 function LcovReport(opts) {
30 Report.call(this);
31 opts = opts || {};
32 var baseDir = path.resolve(opts.dir || process.cwd()),
33 htmlDir = path.resolve(baseDir, 'lcov-report');
34 //patch
35 var rootDir = path.resolve(opts.root || process.cwd());
36 mkdirp.sync(baseDir);
37 //patch
38 //this.lcov = new LcovOnlyReport({ dir: baseDir });
39 this.lcov = new LcovOnlyReport({ dir: baseDir, root: rootDir });
40 this.html = new HtmlReport({ dir: htmlDir, sourceStore: opts.sourceStore});
41 }
- /usr/lib/node_modules/karma-coverage/node_modules/istanbul/lib/report/lcovonly.js
function LcovOnlyReport(opts) {
27 this.opts = opts || {};
28 this.opts.dir = this.opts.dir || process.cwd();
29 this.opts.writer = this.opts.writer || null;
30 //patch
31 this.opts.root = this.opts.root || process.cwd();
32 }
...
45 writer.println('TN:'); //no test name
46 //patch
47 //writer.println('SF:' +fc.path);
48 writer.println('SF:' + this.opts.root + fc.path.replace(/\./,''));
This way lcov file generated has absolute path for SF in lcov.info.
Could this be taken into account for the next version of Istanbul. It will save us a lot of time ? I don't think it is a big fix.
This bug is similar to karma-runner/karma#528, but was not fixed.