Is this repository deprecated/abandoned?

[rennerg]

Link to bug demonstration repository

Expected Behavior

Observed Behavior

Troubleshooting steps

• [ ] still occurring when I put cache: false in my nyc config

Environment Information

# paste the output here

[Swivelgames]

I think most people have moved over to using bcoe/c8

Unfortunately, c8 is broken if you're developing a native ESM module. ~~Otherwise, it works wonderfully~~ and is actively developed.

[jcready]

Otherwise, it works wonderfully

Hard disagree. Regardless of ESM modules c8 (or rather V8) coverage is FAR less accurate with coverage results as it doesn't perform any instrumentation or operate on the AST at all. See https://github.com/jestjs/jest/issues/11188 and https://github.com/vitest-dev/vitest/issues/1252 for more detail, but to summarize:

• V8 coverage (used by c8) tracks "blocks", not individual statements. These blocks just track character ranges which (with the help of sourcemaps) get converted to ranges in the original source code. Because of this you end up seeing coverage (or lack there of) for things like: empty lines, comments, import statements, typescript type declarations, etc. c8 treats every line as a statement even though that's absolutely not the case.
• Instanbul/nyc instruments the code by parsing the code into an AST and then inserts its own code to track how many times a block of code was executed. Importantly it tracks implicit else branches by inserting its own else branch with a counter into the AST if one didn't exist. Same thing for binary operand (x && y), ternary (x ? y : z), and assignment logic (x &= y).

If you're depending on coverage thresholds in CI for a public repo you should be extremely cautious of c8 because contributors can easily game the statement/line coverage results by adding whitespace or multiline comments. They can also game the branch coverage by only exercising the truthy side of a branch.

While c8 is faster than nyc, it's only faster because it's sacrifices a LOT of accuracy.

[Swivelgames]

@jcready Unfortunately, I'm having the same issues. The lack of accuracy makes it really hard to justify continuing to use c8, especially given the lack of traction on c8/34.

It's disappointing that code coverage projects have lost so much traction and attention.