Typescript: Better TypeScript coverage support in Istanbul

[bcoe]

Hello Ben Coe here 👋, I maintain the nyc and istanbuljs test coverage tools.

A good chunk of the bug reports opened on these repos relate to TypeScript parsing:

https://github.com/istanbuljs/nyc/issues?q=is%3Aissue+is%3Aopen+label%3ATypeScript

Given that:

1. TypeScript is wildly popular, and continues to become more popular.
2. folks want to collect coverage information as part of the testing cycle for their TypeScript projects.

I would _love_ to work with you to add better TypeScript support to Istanbul.

Istanbul uses babel behind the scenes for instrumentation, I think that babel-preset-typescript could potentially be a good starting point for pulling this off -- perhaps we could simply swap out the underlying JavaScript parser for a TypeScript parser based on a flag?

Is there anyone on your end who might be interested in this joint project with the Istanbul folks?

_flagging a couple folks on the Babel project too, in case they're at all interested in giving their two cents:_

CC: @hzoo, @loganfsmyth.

[DanielRosenwasser]

Hey Ben, thanks for getting in touch! I think we'd be more than happy to discuss how we could improve TypeScript support for istanbul & nyc. I'll email you and maybe we can set up a call to chat.

[mattwelke]

Feel free to divulge details here. It feels like a miracle coming across this issue. I've been torn between embracing TDD and embracing TypeScript, but right they seem mutually exclusive because of the code coverage issues. I'd love to follow this progress.

@bcoe In particular, I was wondering if you've identified a list of known issues with source maps by now? Any specific types of code that would cause issues with coverage reports, that we can avoid in the mean time?

[smcatala]

note that coverage support works fine with TypeScript (even the latest version 3) and the original Istanbul API, e.g.:
https://coveralls.io/builds/18556837/source?filename=src/index.ts

karma is set up as follows:

• bundling with browserify spec/*.spec.ts -p [ tsify -p spec ] -t [ browserify-istanbul --ignore '**/spec/**' --instrumenterConfig { 'embedSource': true } ] --debug and browserify-istanbul@^2 for the original Istanbul API
• reporting with the json reporter from karma-coverage

the resulting coverage report is then piped through remap-istanbul@^0.8.4, which supports the corresponding json report and produces html for viewing in a browser and lcov for coveralls.

However, I failed to successfully configure the setup for the new Istanbul API with browserify-istanbul@3, karma-coverage-istanbul-reporter and source-map-support.

[kitsonk]

One of the authors of remap-istanbul here... We stopped using it a long time ago. Current versions of istanbul support remapping source maps automatically, essentially what remap-istanbul does. You just transpile your TypeScript as normal and instrument. If you are doing test only transpiles, then inlining the source maps and the sources is the most effective way.

remap-istanbul had no magic with the reporters, it simply was leveraging the coverage reporters that came with istanbul.

This issues seems to be instanbul supporting instrumenting TypeScript directly without transpiling first.

[typescript-bot]

This issue has been marked as 'External' and has seen no recent activity. It has been automatically closed for house-keeping purposes.