Pin every dependency to an exact version
Pinning transitive dependencies to exact versions removes the largest source of builds that differ without the code differing, and makes a bisect a claim about your changes rather than about the internet that week.
Do this firstNothing. This is a place to start.
Exact versions, transitively, recorded in a file that ships with the code.
The reason this sits at the root of the graph rather than beside it is that a floating dependency turns every other signal into a maybe. A red build might be your change or a release upstream. A green one might be green because a broken version has not resolved yet. Once that ambiguity exists, people learn to re-run things, and re-running is how a team stops believing its own gates.
The cost is real but small and one-time: you now have to update deliberately, which is the point.
The decoy
A lockfile that is generated but not committed. It produces identical builds on one machine and floating ones everywhere else, while looking from the outside exactly like the practice that would have worked.
Evidence
- Reproducible Builds: Increasing the Integrity of Software Supply Chains — IIBit-for-bit identical builds are achievable at scale: over 95% of 30,000+ packages, verified by deliberately varying about thirty environmental parameters between two builds and diffing the result. Names the concrete non-hermetic causes found this way — embedded timestamps, filesystem ordering, locale-dependent hashing, build paths.
Last reviewed 2026-08-19.