What coverage measures

Vitest’s v8 coverage provider counts the code a test run executed, from what Node’s V8 engine records. It counts nothing about assertions, so a suite that imports every module and asserts nothing still scores high.

Measured at 86c6966e (2026-11-06) on Node v24.20.0, by the build that produced this page.

Four coverage metrics per library

Every @evanion/* library’s vite.config.ts turns coverage on for each test run, and @evanion/acl’s block reads:

coverage: {
  enabled: true,
  reporter: ['json-summary'],
  reportsDirectory: './test-output/vitest/coverage',
  provider: 'v8' as const,
},

The json-summary reporter writes four percentages to coverage-summary.json in the reportsDirectory above. The table gives each library all four, with the count covered over the count the report found:

• Statements: the statements the run executed.
• Branches: the paths through each if, else, ternary, switch case and short-circuit operator that the run took.
• Functions: the functions the run called at least once.
• Lines: the lines of code the run executed.

Read statements beside branches: a statement percentage well above the branch percentage means lines ran while one path through their conditions never did.

The table leaves out a workspace average and every file a run did not load:

• An average would mislead. Several libraries sit at 100% on all four metrics, and @evanion/acl, which holds more test cases than any other library, sits lower. An average of their percentages gives a library of a few dozen statements the same weight as @evanion/acl.
• The report omits a file no test imported, and the Files in the report column counts the files the run loaded. So 98% there means 98% of what the run loaded, and the library as a whole can sit lower.

Where the branches are not taken

The list below names each @evanion/* library with a file under 100% of its branches, then each such file, and the command that reproduces the figure.

A branch percentage says a path ran, and a case on the security register says what the path decided. SEC-004, a deny rule reading a field the row lacks, and SEC-018, a clock that does not parse, each tie one @evanion/acl branch to the refusal it produces.

What is not built from these numbers

This site leaves four uses of the @evanion/* coverage figures out:

• No coverage badge appears on this site or in any README. A badge shows the percentage with no qualifier and no case beside it. @evanion/acl’s percentage covers about a thousand executable lines of pure functions over frozen JSON, with no network code and no code that parses bytes off the wire. Beside a badge from a project that has both, the higher acl number would suggest the stronger suite.
• No trend line is drawn, because a stored series needs either a committed file that goes stale or a database this static site cannot read.
• No coverage threshold fails a build. Once a build fails under a minimum, the next test someone writes executes a line to clear it and asserts nothing. The build gates the register: tools/repo-checks/src/security-register.test.ts fails when a register entry and its test come apart.
• No package page carries a percentage. A reader on /luhn, the page of the check-digit library @evanion/luhn, who sees 100% has learned that every statement of a small library ran, and nothing about what its tests assert.