Detailed coverage #1

Activity

1. bcoe commented on Oct 26, 2017

   

   bcoe

   on Oct 26, 2017

   Owner

   More actions

   👋

   @schuay thank you for starting the conversation here, this was my motivation for opening this repo.

   I work on Istanbul, which is a popular test coverage library on npm (used both for browser coverage and coverage of of files executed with Node.js). I'm really interested in finding a common approach between how V8 folks think about coverage in the browser, and how Node.js folks think about instrumenting source outside the browser.

   I'm looping in @bmeck to this conversation, who's been doing a lot of low-level work on Node.js recently to support ES modules -- and might be able to speak to the difficulty this extra parsing step presents.

   I will also take the time today to create GitHub issues for the other blockers I mentioned in the README.

   👍React with 👍1Reacted by Jakob Linke
2. schuay commented on Oct 26, 2017

   

   schuay

   on Oct 26, 2017

   Author

   More actions

   FYI I also opened https://crbug.com/v8/7003 on the V8 tracker. Quoting from there:

   An easy approach would be to add flags that enable both features at process start time, before anything is parsed/compiled. It's simple, almost no work, and would be quite easy to use from node. The drawback is that it would need to be passed as a flag when starting node, and could not just be enabled at runtime on a server.

   Does that sound like it would cover common use cases? How important is it to be able to enable/disable block coverage / type profiling in a running node process?
3. bcoe commented on Oct 26, 2017

   

   bcoe

   on Oct 26, 2017

   Owner

   More actions

   I think this would potentially work great, the tool commonly used for coverage in Node nyc already spawns a subprocess (hiding instrumentation steps from the user) this subprocess could just be spawned with Node flags.

   The biggest technical head scratcher I have, is how we'd handle "process.exit()" behavior. We can capture it, but it's synchronous so we can't collect coverage once the process is starting to exit. If we could get detailed coverage with a flag, and figure out this problem, I think the rest of the work is just translating coverage output to something more easily consumed by Istanbuljs reporters (basically just typing).

   CC: @isaacs
4. bcoe

   added

   investigate

   on Oct 26, 2017
5. schuay commented on Oct 27, 2017

   

   schuay

   on Oct 27, 2017

   Author

   More actions

   Awesome, good to know. Continued discussion for process.exit() in #2.
6. bcoe commented on Nov 22, 2017

   

   bcoe

   on Nov 22, 2017

   Owner

   More actions

   in newer versions of v8, we're able to enable block level coverage by starting the inspector with --inspect-brk.
7. bcoe

   closed this as completedon Nov 22, 2017