feat: Node API

[laggingreflex]

This commit attempts to refactor the code to separate the running/reporting/writing logic so that it can be consumed by other libraries

[demurgos]

😄
After many months without any commit, it seems there are two of us working on this project. Following the invalid test results, I refactored both v8-to-istanbul and c8. For the moment I was just fixing bugs, but I agree that a Node API would be very valuable.
When I'll finish fixing the bugs, I'll take a look at your PR and leave review comments. If it's good, I'll rebase it on top of my changes.

[demurgos]

I had some time to look at your proposal.
I think that this is the API we should strive for in the long term, but I don't think it is currently safe to provide this kind of API.
What I mean is that it'd be great to just pass a function and then get coverage results for it, but it does not work well with the isolation of the executions. c8 has a client/server architecture where the server wraps all the node processes in its process sub-tree. Then each node invocation starts a client. The client bootstraps the profiler, delegates the execution to the original program and then return the results to the server by writing them in a temporary file. When the sub-process tree ends, the server reads the results from the files left by all the clients and generates the reports.

From what I see, your current API proposal is intended to be executed at the client level. It has a few issues:

• Spawned sub-processes are not covered.
• You cannot call your API multiple times: the coverage is global per process, not "scoped" to a single instrumented function call.
• Even if you were to be able to call your API multiple times (by manually handling scope issues), there would be concurrency concerns (for example regarding module caching).
• This API is not the Node equivalent of the CLI: the CLI works with sub-processes.

Providing helpers for reporters is fine. There's probably some bike-shedding if it should return V8 reports and let the consumer convert them to Istanbul's format or not. (So c8 would be less reliant on Istanbul and could be used by other kinds of reporters.)

I'd start with a more conservative API with similar capabilities as the CLI (so the CLI is just a wrapper of the Node API). The instrumented code would still have to be executed in its own sub-process. What I would provide is a function with an API similar to child_process.spawn but instead of returning a ChildProcess, it would return a promise for coverage reports collected by executing the corresponding command.

[bcoe]

@demurgos @laggingreflex 👋 sorry for not having helped steward this project in recent months.

This project started out mainly as a proof of concept, to prove out whether or not we could potentially use v8's native test coverage for Node.js projects. Well things work relatively well, I ultimately landed on the opinion that we'd do better to try to integrate things more tightly into Node.js itself.

I'm hoping to continue working with @hashseed @schuay to better define what this would look like.

If you're interested in joining this conversation, or want to bounce any ideas off of me related to c8, I can be found in chat here:

http://devtoolscommunity.herokuapp.com/

[bcoe]

@laggingreflex see #22