Add support for ES6 and Code Coverage

[phillipskevin]

Some ES6 syntax breaks Istanbul instrumentation.

[phillipskevin]

Switching to isparta is simple and allows coverage to work on the project I was having trouble with. Should this be done by default whenever running with coverage, or do we want to allow the user to choose which coverage instrumentation to use? If a project is already running testee with their transpiled files, they might not want to transpile again.

/cc @daffl

[daffl]

We should probably make it configurable. It looks like this one only works with Babel?

[phillipskevin]

Right, it just runs babel and then Istanbul. I haven't done too much research on other alternatives to isparta.

[justinbmeyer]

Can someone walk me through this?

There's steal, testee, instanbul, and babel.

What does what, where do things go wrong?

My assumption on a "perfect" solution would be steal uses babel and an instanbul plugin to babel to transpile all code to be instrumented.

Testee would just run the tests as normal, but be looking out for some signal that there's code coverage information.

[daffl]

What it currently does is instrument the JS files on the server before sending them. This works for any ES5 JavaScript file (also with anything like Browserify, Webpack and server side Babel that builds things first).

The problem is that the instrumentation even with the 1.0-beta Istanbul that supposedly works with ES6 as far as I could get it to work creates output that does not work with Steal when it loads the individual files on the client.

[ccummings]

A new babel plugin exists that generates a coverage variable for es6 code. Not sure if it suffers from the same problem as istanbul today.

[matthewp]

I'm confused as to how Instanbul instruments on the server. Does it overwrite files? Like if I have a file foo.js it changes the contents of foo.js on my filesystem (and presumably restores it back afterwards)? Is this what happens?

[daffl]

It instruments them on the fly with connect-injector just like when it adds the client script to HTML test files.

[matthewp]

I see, so if you are using a bundler the source has already been transpiled, but in the case of Steal it is has not.

Would it be possible to allow the user to hook into this pipeline so they could insert their own transpilation prior to the instrumentation step? That way you could possibly transpile just the import statements to commonjs before instanbul gets to it.

[matthewp]

Talking about this problem a bit more, it feels like me the solution would be to use their Babel plugin (and only their Babel plugin) to add the coverage code on the fly, the same way that Testee currently adds the coverage code using the old Istanbul API (which internally uses an old Esprima version).

This would be a minimal change, only changing how coverage is added

Note: this would only run the istanbul babel plugin. It wouldn't transpile class syntax or import/export or anything else.

[phillipskevin]

I'm going to give this a try.

[phillipskevin]

This is closed in v0.4.0. Nice work @andrejewski finishing this off!