Documentation
Reviewing a change
Ask what a change introduced before it lands, instead of scoring the whole repository again.
Scoring a repository tells you where the old problems are. A change asks a different question: did this edit introduce something that was not there before? Supercov asks that directly.
npx supercov quality patchReviewing unstaged changes.
src/session.js
0.93 deep_nesting
0.82 complex_conditional
0.80 long_parameter_list
0.79 magic_valuesNothing here is a score. Each line says a property appeared in this edit, and how confident that answer is.
Both versions go in together
For every changed file, the version before the edit and the version after it
go into one request, and the question is what after shows that before did
not. That is why it can be pointed at code that was already messy: a file that
scores weak has nothing to lose, but an edit that adds a fourth level of
nesting to it still shows up.
Choosing what to compare
With no options it picks the range from the state of your tree.
| Your tree | What it reviews |
|---|---|
| Uncommitted edits present | The working tree against the index |
| Only the index is ahead | What a commit would contain |
| Clean | Everything since this branch left its default branch |
You can say so explicitly instead:
npx supercov quality patch --staged
npx supercov quality patch --base origin/main
npx supercov quality patch src/session.jsRisks a change can carry
A change is also asked six questions that only make sense about an edit: does it add a hardcoded secret, build a query or command from untrusted input, touch authentication or permissions, weaken or delete a test, migrate data irreversibly, or leave debugging behind.
These stay quiet on ordinary work. On a routine change, expect around one to fire, and read it rather than trusting it: each one is a judgment about the diff, and the diff is in front of you.
In continuous integration
npx supercov quality patch --base origin/main --annotate github--annotate github prints workflow annotations to stdout, so findings appear
on the changed lines. It posts nothing and calls no API of its own.
Crossing the findings with a coverage run shows which of them landed in code no test exercises:
npx supercov quality patch --base origin/main --run latestWhat it will not find
This is a structural check, not a code review. Measured against a published set of review comments from real pull requests, the twelve properties had a word for about one comment in twelve, and most of what reviewers actually wrote about were bugs — wrong conditions, missed cases, bad assumptions. Those are what your tests and your reviewers are for.
Read it as one more signal beside coverage and assertion coverage, and keep the reviewer.
Read more in the terminal
npx supercov docs quality
npx supercov quality --helppatch reads your working tree and writes nothing to it.