Thoughts

[jamestalmage]

Interesting approach to the problem. I think it has promise. Just a couple thoughts:

• As a Babel plugin, I do not think this is a likely solution for CoffeeScript or TypeScript. They use their own parsers and AST. Unless they decide to throw out their current parser solutions and move to Babel, I just think it's really unlikely. There is talk of making the Babel parser extendable, but it's a low-priority, far in the future thing (Other languages moving onboard is probably even further out). I don't necessarily see this as a big problem. If copenhagen proves to be a more reliable solution than istanbul, then it can serve as a model for other languages - and prove that "cover before transpilation" is a good strategy.

• A bigger concern is what this is going to do to power-assert. If power-assert is applied second, I fear it will completely muddle the output. There may be other transforms to be concerned about, but I'm not sure.

• I just saw a PR on Babel that fixed some source-map stuff. I wonder if that fixes any of our issues.

• I doubt you are going to escape the need for exit handlers. From the docs:

  Tools like nyc can use this module to get a stream for the collected data. This data can then be piped to disk, alleviating the need for exit handlers

  Much of the work that went into signal-exit was to address the issue of coverage data not making it to disk before the process exits.

  var stream = fs.createWriteStream('/some/path');
  
  // this isn't guaranteed to make it to disk if you force exit the process.
  stream.write(largeChunkOfData);
  process.exit();
  

---

As I said, I think there's promise. You are certainly trying to tackle a real problem, istanbul has struggled to get transpiled code right for a long time, so I think a replacement is worth pursuing. I think this approach might work. I just wanted to give you some food for thought.

[novemberborn]

As a Babel plugin, I do not think this is a likely solution for CoffeeScript or TypeScript.

Yes, we'll need a compatible implementation of instrument for languages like those. Easy enough to package up and select based on file extension in nyc.

A bigger concern is what this is going to do to power-assert.

You wouldn't typically instrument test files though.

I just saw a PR on Babel that fixed some source-map stuff. I wonder if that fixes any of our issues.

Perhaps. It strikes me though that translating coverage is always going to be flawed.

I doubt you are going to escape the need for exit handlers.

Yea I'm afraid of that too. At least it'll be possible to build a streaming coverage reporter ;-)

[jamestalmage]

You wouldn't typically instrument test files though.

Good point.

It strikes me though that translating coverage is always going to be flawed.

I think you are right.

[sindresorhus]

As a Babel plugin, I do not think this is a likely solution for CoffeeScript or TypeScript.

I don't think this should be a big concern. Our main focus, at least with AVA, is ES20xx.

[sindresorhus]

This project is a really good idea. I fully support it. 👌