-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Documentation Request - pros / cons vs Istanbul #281
Comments
One major use case: if you need coverage for ESM projects. |
Thanks @aral I wonder if c8 would work on V8 processes inside electron. |
@bd82 Haven’t tried it but I don’t see why not. Give it a shot and let us know? ;) |
If you can get access to the inspector api or dump the internal coverage data in some way, you can use c8's report function to report on coverage. We have a v8 environment that is non-node/non-electron and this is how we get code coverage. We basically invoke the inspector APIs directly, write the data to temp location and then use c8 to create our coverage reports. c8 also might be faster for large code bases? I don't actually know if this is true as I have not tested it for node. But in theory the lack of an instrumentation phase would arguably make a CI build faster. That was the case for us, but the comparison was with a very, very old and highly customized fork of nyc so it may not be true today or in general. Perhaps worth a test though? |
Unfortunately I don't seem to find the time to investigate C8 + VSCode extensions coverage... But I found some info related to my original question here: |
Hello.
I've only recently discovered C8 and was wondering how does it compare to Istanbul?
I'm making a semi educated guess that removing the need for instrumenting the files would make C8 significantly faster.
And that collecting coverage from multiple sub-processes may be easier.
Basically when should I use NYC/Istanbul and when should I use C8?
The text was updated successfully, but these errors were encountered: