JavaScript & TypeScript · Comparison
c8 vs nyc: JavaScript coverage compared
Compare c8 and nyc coverage with the same JavaScript fixture. See how collection, source maps, and coverage criteria affect the result.
The short answer
Choose c8 when you want to collect coverage from Node’s V8 runtime. Keep nyc when your project already uses Istanbul instrumentation and that setup works well. Neither choice requires changing your test framework.
nyc is Istanbul’s command-line tool. c8 collects V8 coverage and can use Istanbul’s reporters. Similar-looking reports do not mean the collection methods—or the things they count—are identical. See the c8 documentation and nyc documentation.
Run the same suite
For a Node test suite with source files in src:
npm install -D c8
npx c8 --all --include='src/**/*.cjs' node --test
The corresponding nyc command is:
npm install -D nyc
npx nyc --all --include='src/**/*.cjs' node --test
Use your actual source extension and test command. Keep generated files out of the source scope. The --all option includes eligible files that the tests never load; otherwise a high percentage can hide entire untested files.
For TypeScript, check that the report points to your original source, not only the compiled JavaScript. c8 supports source-map remapping. nyc documents a TypeScript configuration preset. Neither command replaces your compiler or test runner.
Why their percentages can differ
We ran both tools against the same small CommonJS fixture and Node test suite. These are the recorded totals:
| Tool | Lines | Branches |
|---|---|---|
| c8 12.0.0 | 11/11 | 6/6 |
| nyc 18.0.0 | 6/6 | 4/4 |
Both show 100%, but use different denominators. Do not treat a changed percentage after switching tools as proof that your tests improved. Inspect the highlighted source and the missing cases.
Our fixture exercises both outcomes of signedIn && !expired, but never tries a signed-in session that has expired. Neither standard report measures whether each condition independently changes the decision. That is the question MC/DC answers.
What Supercov adds
Supercov is another way to measure the existing suite, with MC/DC, per-test coverage, and source-to-assertion review. It does not replace c8 or nyc’s reporting workflow one-for-one.
| Feature | c812.0.0 | nyc / Istanbul18.0.0 | Supercov0.0.47 |
|---|---|---|---|
| Line coverage | Supported | Supported | Supported |
| Branch coverage | Supported | Supported | Supported |
| MC/DC | Not built in | Not built in | Supported |
| Per-test coverage | Not built in | Not built in | Supported |
| Assertion coverage | Not built in | Not built in | Supported |
✓ Supported · × Not built in. Standard coverage workflows in the versions shown; custom plugins are outside this table.
Vitest uses its standard V8 or Istanbul coverage provider here. Supercov works with your existing test runner.
Per-test coverage means individual tests, not just test files. Supercov needs a supported runner. Assertion coverage links source to checked properties through agent review; it is not a mutation score or a correctness guarantee.
npx supercov -- node --test
npx supercov runs latest gaps
If your goal is to find unexecuted code in a familiar coverage report, c8 or nyc may already be enough. If a green report still leaves you asking “which condition or result did we never check?”, use the deeper measurements to investigate.
Using Vitest? Prefer its integrated providers over wrapping it in another collector. See Vitest coverage: V8 vs Istanbul.
Example evidence: fixture source and recorded results (JSON). Measured September 13, 2026. These small examples are not a performance benchmark or a general conformance test.