coffee-coverage and CoffeeScript 1.11.x (ES2015 modules)

[wcjohnson]

With the release of 1.11, CoffeeScript has begun moving toward the ES2015+ standard. In particular, CoffeeScript now supports ES2015 import/export directives.

These do not play well with coffee-coverage right now, producing errors like this:

> mocha --recursive --compilers coffee:coffee-script/register --require coffee-coverage/register-istanbul

/Users/wcj/dev/ormojo/node_modules/ormojo/node_modules/coffee-coverage/lib/coffeeCoverage.js:321
      throw new CoverageError("Could not compile " + fileName + " after instrumenting: " + err.stack);
      ^
CoverageError: Could not compile /Users/wcj/dev/ormojo/node_modules/ormojo/src/Backend.coffee after instrumenting: SyntaxError: export statements must be at top-level scope

Presumably, export and import statements should simply be ignored when instrumenting, as they are meant to be declarative.

[Florian-R]

I'm currently having troubles with this too. I've toyed with this a bit, this error is caused because the code is instrumented by default with the bare options set to false by default.

It's still unclear to me how we can set this options when using coffee-coverage/register-istanbul.

Anyway, code compiled with bare blow mocha anyway, as mocha doesn't understand the import statement, and we can't chain coffee-coverage/register-istanbul or coffee-script/register with babel-register.

Out of curiosity, @wcjohnson did you find a solution which doesn't involve to compile your sources before running the tests?

[wcjohnson]

@Florian-R

I'm afraid not. I've just been running coverage on the transpiled code, then mentally translating it back to the CoffeeScript. It's workable but ugly.

[Florian-R]

@wcjohnson I've achieved something that does the job. See chaplinjs/chaplin#895. This one use grunt but I think you could achieve something similar from the CLI, maybe by wrapping the instrument part in a script.

I'd like to get rid of having to define the global variable manually, but this breaks with babel-register. Here, the coverageVar is set as a global if not defined, and this don't play well with use strict.

@jwalton will you be OK with a PR that switch to something like ?

init = """
  if (typeof #{@coverageVar} === 'undefined') global.#{@coverageVar} = {};

This is a simple example. This will need some tweaks to catch the correct global for browsers.

[jwalton]

@Florian-R Yeah, if you can do this correctly for browsers, I'm happy with it.

If you want to try compiling with bare: true you need to write a custom loader to use in place of coffee-coverage/register-istanbul.

@wcjohnson coffee-script compiles this to a JS file with imports and exports in it, yes? But node 6/7 don't support import and export natively, so how are you even going to run this? Does it go through Babel afterwards? If you have a sample project, I'd be interested in seeing it.

[wcjohnson]

@jwalton

Yes, coffee-script passes the statement through, and indeed Node does not handle ES2015 modules (and won't for awhile, according to the word on the street) -- but I'm writing isomorphic code and on the browser side things are moving more quickly.

There is a Babel step at the end of my build chain that generates a CommonJS build and an ES2015 build. The tests are run in Node under the CommonJS build.

This project uses my current best build and coverage chain: https://github.com/wcjohnson/redux-components

You will need to have nyc installed; then npm run coverage should work.

As I said above, since moving away from coffee-coverage I'm stuck just transpiling and running coverage on the resulting JS, then "mentally translating" the coverage reports back to CS. I've tried source maps and they just don't work right. It would be nice to run through coffee-coverage for proper instrumentation, then through Babel.

[jwalton]

I think this can be done. Back when I first started integrating with Istanbul, they'd use a randomly generated coverage variable, which was obnoxious because you couldn't instrument your code ahead-of-time, but I'm pretty sure nyc always uses "coverage". I'll clone your project and see what I can do.

On Feb 26, 2017 12:54, "William C. Johnson" notifications@github.com wrote:

@jwalton https://github.com/jwalton

Yes, coffee-script passes the statement through, and indeed Node does not handle ES2015 modules (and won't for awhile, according to the word on the street) -- but I'm writing isomorphic code and on the browser side things are moving more quickly.

There is a Babel step at the end of my build chain that generates a CommonJS build and an ES2015 build. The tests are run in Node under the CommonJS build.

This project uses my current best build and coverage chain: https://github.com/wcjohnson/redux-components

You will need to have nyc installed; then npm run coverage should work.

As I said above, since moving away from coffee-coverage I'm stuck just transpiling and running coverage on the resulting JS, then "mentally translating" the coverage reports back to CS. I've tried source maps and they just don't work right. It would be nice to run through coffee-coverage for proper instrumentation, then through Babel.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/benbria/coffee-coverage/issues/82#issuecomment-282573638, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsF-4opDi7T1lXTKcpR4IMcvRab0DE1ks5rgbxBgaJpZM4KkM-O .