Support source maps for html report

[jasonpincin]

HTML report should support source maps. This would allow the reports to be far more digestible when running against browserify bundles (https://github.com/substack/node-browserify).

[gotwarlost]

That sounds like a lot of work :)

I agree that this is very useful. Let me think about this to figure out a solution.

[gotwarlost]

I would like to understand how you are running your tests with browserify and istanbul in the mix because I suspect that there is no use case for istanbul to consume browserify source maps.

Consider this sequence:

1. Instrument the original sources using istanbul (which now has references to the line/column information of the original source files)
2. Combine the instrumented versions into a bundle using browserify
3. Run tests on the bundle which will write information into the global coverage object using original source information
4. Dump this coverage object at the end of your tests and run reports on it.

Step (4) should still work in the above sequence and give you coverage info w.r.t to the original sources.

Now, it may be that istanbul needs additional flags based on your use-case to be able to extract the correct coverage global but that should be an implementation detail which we can work together to fix.

Conceptually I do not see the need for istanbul to deal with browserify source maps. Thoughts?

[jasonpincin]

This is a case of me opening my mouth before exploring all the options available. Instrumenting the code before bundling works great.

Thanks @gotwarlost

[tcmitche]

@jasonpincin I am trying to set up a similar configuration, istanbul coverage reports on browserified js, but am having trouble. Would you be able to elaborate on your solution? Do you have a working example?

[jasonpincin]

@tcmitche We use a Makefile along the lines of:

bundle:
    @istanbul instrument --output lib-cov lib
    @ls -1 test/unit | awk '{print "require(\"../unit/"$$1"\")"}' > test/bundle/_unit.js
    @browserify --fast --debug test/bundle/_unit.js > test/bundle/unit.js
    @rm -f test/bundle/_unit.js

test: bundle
    @mocha-phantomjs -R tap test/unit.html

You can get a lot fancier, but that's the basics.

[Raynos]

Would love to follow up on this browserify issue.

Having to do a lib-cov thing sucks because it doesn't work for non trivial apps. i.e. apps that have source code on the top level.

The fact that instanbul just works is great for node.

I would love an instanbulify command that runs browserify on a file and generates a bundle with istanbul commands that writes to window.__coverage__ and also prints the report set on --report to console.log.

I'll see if I can build this :)

[devongovett]

I wrote a browserify transform for instanbul here. It works pretty well, especially when combined with karma-coverage for reporting - generates the same HTML output as in Node.

[kirill-konshin]

@gotwarlost you said "there is no use case for istanbul to consume browserify source maps" - there is... :)

I compile my TypeScript sources to JS and then execute Mocha tests. Coverage, that I see, is generated for generated JS files.

You can take a look on it here: https://github.com/kirill-konshin/typescript

[XeCycle]

I vote on re-opening this, for support on languages compiling to js.

In my case I write in ECMAScript 6, and have my code transpiled by 6to5; the output code is still readable, yes, but it differs from the original code.

Anyway supporting source maps seems easier than supporting every language in the wild.

[arielschiavoni]

@XeCycle +1

[pascalduez]

Just a mere +1
ES(6|2015) transpilation is growing exponentially on projects, it would be great to be able to link to source code.

[alinex]

+1

[robertlevy]

+1 (though i wouldn't limit this to just html reports)

[lukeapage]

@gotwarlost are you seeing these comments?

+1
I am compiling using babel and would like to have the code coverage reports mapped to my input.

This also related to #308 - you could perhaps be clever and allow code that doesn't map back the input to not be marked as not covered?

[wojciak]

+1 Compiling typescript -> js

[acromarco]

+1 Compiling typescript -> js

[btesser]

+1 typescript -> js

[lukeapage]

This issue appears to now be covered by #212

[louy]

I was able to map back my coverage reports using source maps (I'm using typescript).
If anyone is interested, take a look at this repo.

Basically I'm just using lcov-sourcemap by Tapad. You'll want to look at files package.json, scripts/map-coverage.js and circle.yml.

Here's the final report for .ts files: https://codecov.io/github/urbanmassage/opool

[nmn]

Here's another great package for dealing with source maps: https://github.com/SitePen/remap-istanbul

[Izhaki]

For anyone interested in mapped coverage reports involving:

• Typescript
• Jasmine / Mocha
• tsc
• npm scripts

This may be of help:

Output

Jasmine

See https://github.com/Izhaki/Typescript-Jasmine-Istanbul-Boilerplate.

package.json (the relevant stuff):

{
  "scripts": {
    "postinstall": "typings install dt~jasmine --save --global",
    "test": "ts-node node_modules/.bin/jasmine JASMINE_CONFIG_PATH=jasmine.json",
    "test:coverage": "ts-node node_modules/istanbul/lib/cli.js cover -e .ts  -x \"*.d.ts\" -x \"*.spec.ts\" node_modules/.bin/jasmine -- JASMINE_CONFIG_PATH=jasmine.json"
  },
  "devDependencies": {
    "istanbul": "^1.1.0-alpha.1",
    "jasmine": "^2.4.1",
    "ts-node": "^0.9.3",
    "typescript": "^1.8.10",
    "typings": "^1.3.1"
  },
}

Mocha

See https://github.com/Izhaki/Typescript-Mocha-Istanbul-Boilerplate.

package.json (the relevant stuff):

{
  "scripts": {
    "postinstall": "typings install dt~mocha dt~require dt~chai --save --global",
    "test": "mocha --compilers ts:ts-node/register src/**/*.spec.ts",
    "test:coverage": "ts-node node_modules/istanbul/lib/cli.js cover -e .ts  -x \"*.d.ts\" -x \"*.spec.ts\" _mocha -- --compilers ts:ts-node/register -R spec src/**/*.spec.ts"
  },
  "devDependencies": {
    "chai": "^3.5.0",
    "istanbul": "^1.1.0-alpha.1",
    "mocha": "^2.5.3",
    "ts-node": "^0.9.3",
    "typescript": "^1.8.10",
    "typings": "^1.3.1"
  },
}

[pygy]

With the 'instrument before bundling' approach, you need to build the project every time you want to get coverage data, even if you only touched the tests. That is sub-optimal as it takes more time and CPU power than just re-running the tests on a built artifact that has a source map (unless the source map processing and line translation takes more time than compiling a project, but that would surprise me).

Having something like istanbul-remap builtin would be nice (for me as a user) as it would remove a moving piece of the setup.

@gotwarlost: Any chance you could at some point work with the SitePen/Dojo folks to upstream the remap-istanbul core in Istanbul itself? It would solve #212 for all transpiled languages that support source maps (meaning, each and every serious one).

Pinging @kitsonk and @jdonaghue as well, upstreaming the core would allow you to ditch the various task runners and pre-processor plugins that you have to maintain.

Edit: for one, you use the same license (BSD-3-clause), that's already one hurdle out of the way...