Hey Demurgos,

Having been one of the folks who inflicted spawn-wrap on the world, I 
couldn't be more excited to retire it...

I've been advocating that we better expose v8 code coverage in Node.js 
itself; in a perfect world you'd do something like this: `node --coverage 
foo.js` and along with executing your code, you'd get Istanbul format JSON 
written to disk which could then be used for reporting.

I'm going to make an effort to better define this work with Jakob, Yang, 
and others over the next few months. Would love feedback from other folks 
within the community as we work on a proposal -- what's the ideal?

-- Ben.

On Thursday, August 9, 2018 at 12:05:13 AM UTC-7, Jakob Gruber wrote:
> +yang who can say more about node.
> We (Ben, Yang & myself) recently discussed the possibility of adding 
> coverage support to node itself. See here 
> <https://docs.google.com/document/d/1-BBdxe9_zIm9161_YQgKixL5mrM0rID9XuhcdDERYtA/edit?usp=sharing>
> for a (very rough and early stage) doc with some thoughts.
> On Wed, Aug 8, 2018 at 10:22 PM, demurgos <demurg...@gmail.com 
> <javascript:>> wrote:
>> Hi,
>> I work on Node.js code coverage tools using V8's profiler (c8).
>> There are currently 2 methods to use the V8 debug protocol from Node.
>> 1. You can spawn a process with the  `--inspect` or `--inspect-brk` flag. 
>> This starts V8 in "server mode" and remote clients can connect to it and 
>> interact with the debugger.
>> 2. You can use Node's "inspector" module to enable a process to debug 
>> itself (communicate with its own V8)
>> This means to profile a V8 runtime, you need to first start the V8 
>> process and then connect the inspector to it.
>> This system causes a mismatch with the needs of coverage. nyc (istanbul) 
>> and c8 want to get coverage for all the node processes spawned in a process 
>> sub-tree.
>> We have a single top process collecting coverage and each Node subprocess 
>> reports its results to it.
>> This means that we have the opposite system: the inspector is started 
>> first, and then many debugged processes connect to it.
>> But this is not supported by V8.
>> So we use a "brutal hack" called "spawn-wrap".
>> It intercepts all the Node processes created in a subtree and replaces 
>> its main module by another one. This wrapper module has the logic to start 
>> the profiler, execute the original entry point and then report the results.
>> This solution is far from optimal. The wrapping mechanism is complex and 
>> hard to maintain, if the entry point forces the process to close 
>> immediately the reporting code is not executed, and the execution of the 
>> wrapper entry-point can interfere with the the coverage.
>> Some of these issues can be solved, but the mismatch remains: we have to 
>> engineer a level on top of the V8 debugger because the connection can only 
>> go in one direction currently: the inspector connects to the debugger.
>> I would like to know what it would take to support the opposite scenario: 
>> start an inspector server on some port (ex 9333) and then ask the debugger 
>> to initiate the connection.
>> It would act like:
>> inspectorServer.on("connection", (client) => {console.log("New 
>> connection");})
>> await inspectorServer.start();
>> spawn("node", ["foo.js"], {env: {NODE_OPTIONS="--inspect-srv=9333"}});
>> Ensuring that all the subprocesses have the same env var or flag is 
>> easier to achieve than hijacking the entry-point to emulate this kind of 
>> feature.
>> I believe that this kind of feature needs to be implemented in V8. Am I 
>> right? Should I redirect this feature request to Node? Is it the right 
>> place to post this message?

v8-users mailing list
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to