Javascript coverage architecture/design
saranrapjs opened this issue · 0 comments
Hi! I've been tinkering with adding support for Javascript coverage within Storycap. Here's my fork's branch which (mostly) works with some of the e2e.sh examples. This uses an updated version of Puppeteer, which emits Chrome's raw v8 coverage files, and then converts them to an Istanbul-compatible compatible coverage output.
Is this contribution something, generally speaking, you'd welcome?
There are a number of other pieces that I'd need to line up in order for this to work (there are no tests, there was one bug that I've not yet documented in this code, etc). But the most glaring TODO is that larger storybook instances (with hundreds of stories) can cause the storycap node process to run out of memory. This isn't all that surprising, given that right now on the branch the coverage code accumulates individual coverages from each worker's story specific execution:
...and these chunks of coverage data are quite large when emitted, with a lot of overlap between stories has to be deduplicated later on because of the separation between storycap worker processes.
Another way to approach this would be to collect coverage from all workers all of the time (when coverage is enabled), and then attempt to emit and dedpulicate coverage data only once all workers have completed screenshot tasks. I'm happy to give this a shot, too, but figured I should probably share where I'm at here first to make sure I'm not totally off base with any existing notions you all may have had in mind with coverage in Storycap!