Issue with generating lcov/html reports for traceur-compiled files

[caitp]

I'd like to get some test coverage reports in a nice lcov format for some code, which is currently written in traceur-compatible ES6 (compiled with the amd/requirejs module mode). Tests are being run by karma, with the karma-coverage plugin (everything is configured correctly).

I can actually generate text coverage reports just fine, but I'd like to generate lcov/html coverage reports to eventually host online. The issue is that for whichever reason, in annotateLines, structuredText does not always contain a line number from lineStats --- actually, this problem comes up in a few different ways, in the library.

Admittedly, this might be a pebkac issue, since it's my first time trying to use istanbul (I've had plenty of experience with gcov and lcov, though!), but it's very annoying.

I'm happy to have a go at figuring this out and submitting a patch, but if it's a known issue with a workaround or something, I'd love to hear about that.

[gotwarlost]

If this is happening, it most probably means that istanbul isn't seeing the original source when trying to generate reports. Typically this happens when people instrument files in place so now istanbul is trying to find the original line in the minified instrumented file.

I don't accept any patches for such "fixes" because the problem should never happen if istanbul is indeed reporting on the exact same file contents that it processed and all such patches are workarounds for a deeper problem.

[caitp]

Well it's not instrumenting the original sources, it's instrumenting pre-processed sources (it will throw if you do it the other way around, apparently it doesn't like ES6 module syntax). It may or may not be being fed a sourcemap.

Looking at the API it doesn't appear to actually care about sourcemaps anyways, regardless of whether one is present or not.

[caitp]

So, a sourceMap comment is being inserted into the source by the karma-traceur-preprocessor, decoding the source map should provide information about which lines should be worried about. Maybe if a sourcemap is present, it would make sense to perform a lookup to find the line in the original file? This should work well for coffeescript and typescript and other preprocessed languages as well.

[gotwarlost]

@caitp - thanks for the explanation. Do you have a github repo that you can point me to that demonstrates this problem?

[caitp]

the repo I've been wanting to add better coverage reports to is at http://github.com/caitp/watchtower.js (currently I just have html reports disabled, but it's easy to reproduce by re-adding them in karma.conf.js), but the same problem should affect any repo which wants to use the karma coverage preprocessor after the traceur preprocessor (regular javascript and coffeescript work fine due to JS not really being preprocessed, and ibrik's hacks to get around the issue) --- so you could reproduce it in http://github.com/angular/templating and others as well.

I mentioned it to the manager of the Angular team and he said we might need to contribute some fixes to traceur-compiler and/or istanbul so that we can deal with this better

[jackwakefield]

I've created an instrumenter which can be used with karma-coverage called ismailia.

An example of the setup is here.

[mwq27]

So if we need Istanbul to run on the original source files, when using a tool like browserify, should I run the coverage on the source before browserify touches the files? I have a project using Angular with Browserify (transform with Babelify), and I'm trying to get HTML coverage working with Karma coverage. I am able to babelify the files into a separate directory, then run istanbul directly on those, and it seems to work. it's just not working in Karma Coverage.

[silkentrance]

@gotwarlost again, a utilisation issue. Might be closed for good.