Pull request checklist
Fourteen checks to run against a branch before it merges, grouped by what a green pipeline still lets through. The first group is what the machine can decide on its own, and the point of running it locally is that the same command fails faster on your laptop than in a queue. The second group is the one CI usually gets wrong rather than skips: a coverage number computed from a denominator that counts only the files a test happened to import, a gate that passes with a file at zero, a test that passed on the second attempt and reported itself as passing. The third group is what a reviewer cannot see in a diff, because a dependency added by something you did add, a secret removed in a later commit, and a lockfile that no longer matches the manifest all look like nothing at all in the files changed view.
14 checksabout 96 min end to end
What the machine can decide
- How to check typescript errors
The editor reports the files it has open and the compiler reports the project, and the two disagree most on the file nobody opened. - How to check eslint errors
A rule that is configured but not running produces a clean report, so the check is that the linter saw the file, not that it said nothing. - How to check prettier formatting
A formatting diff buried inside a behaviour change hides the behaviour change, and the fix is a check that fails rather than a reviewer who notices. - How to check node version of a project
The version in the engines field, the version in CI and the version on the machine that ran the tests are three separate facts, and only one of them is in the pull request.
What a green pipeline still lets through
- How to check test coverage
The default denominator counts only files a test imported, which reports 100% on a project with untested files, and a test containing no assertion still raises the number. - How to check branch coverage
A file at 100% lines can sit at 50% branches, and the uncovered line numbers name lines that executed, which is why the line number alone tells a reviewer nothing. - How to check code coverage threshold
The same gate passes or fails depending on which denominator it is measured against, and a per-file rule reports itself as a global one when it fails. - How to detect flaky tests
Retries are not independent attempts, so a suite configured to retry twice still lets through a test that fails once in thirty runs, reported as passing. - How to check which tests are slowest
The slowest test and the slowest file are different answers, and a suite where most of the wall clock is transform and import time will not get faster by fixing a test.
What the diff does not show
- How to check if package lock is in sync
A manifest edited without regenerating the lockfile installs different versions on the next machine, and nothing in the diff says so. - How to check npm packages for vulnerabilities
The advisory that matters arrived after the branch was cut, so the answer depends on when the check runs, not on what the branch changed. - How to check why a package is installed
A dependency added by a dependency is invisible in the pull request and is the usual source of an unexplained new package in the tree. - How to check npm package licenses
A transitive licence change is not reviewable in a diff, and it is the kind of problem found long after the merge, by someone else. - How to check for secrets in a git repository
Deleting a file in a later commit leaves the value reachable in the history, so a branch can be clean at the tip and still carry the credential.
Take it with you
The file is the same list as Markdown checkboxes, ready to paste into a release ticket or a pull request description.
Ticks are kept in this browser only. They are not sent anywhere and other people do not see them.