Dependency pinning / lockfile
The build broke today and nobody changed code. A lockfile records exact dependency versions so every machine installs the identical tree.
See it
What it is
A version range like ^1.2.0 means 'any 1.x newer than this', so two installs a week apart can pull different code. A lockfile is the generated receipt of what actually got resolved: every direct and transitive package, its exact version, and its integrity hash. package-lock.json, bun.lock, pnpm-lock.yaml, Cargo.lock, and uv.lock are all the same idea. Go splits the job in two, which trips people up: go.mod selects which module versions you get, while go.sum only records integrity hashes for them. go.sum is the tamper check, not the lockfile.
Reach for it the moment more than one machine builds your code. Commit the lockfile, then make CI install from it rather than re-resolve: 'npm ci', 'bun install --frozen-lockfile', 'pnpm install --frozen-lockfile'. Applications do not have to write exact versions into the manifest to be reproducible: a committed lockfile plus a frozen install already decides the whole tree, and ranges in the manifest just describe what an upgrade is allowed to move to. Libraries publish ranges and cannot lean on a lockfile at all, because yours is ignored the moment someone installs your package as a dependency.
Gotcha: pinning is not a security strategy on its own, it just freezes whatever you froze, bugs included. Pair it with an update bot (Renovate, Dependabot) so upgrades arrive as reviewable PRs. Also note a lockfile pins packages, not the world around them: Node version, system libraries, and postinstall scripts can still shift underneath you, which is why lockfiles and container images tend to travel together.
Ask AI for it
Make dependency installs reproducible in this repo. First detect the ecosystem and the package manager actually in use from the manifests and lockfiles present, then work only in that ecosystem's native terms. Commit its lockfile, switch every CI and container install step to its frozen install command (for example 'npm ci', 'bun install --frozen-lockfile', 'pnpm install --frozen-lockfile', 'uv sync --frozen', 'cargo build --locked', or 'go mod download' with 'go mod verify'), never a plain install, and fail CI when the lockfile is out of sync with the manifest. Pin the runtime version using that ecosystem's own mechanism rather than inventing one. If the repo already has a dependency update bot configured, tune it to group non-major updates into one weekly PR and send majors separately; if it has none, recommend one and tell me why, but do not assume which.