Lockfiles

Lockfiles capture the exact resolved dependency graph: versions, integrity hashes, nested packages, and sometimes peer resolution metadata. They make installs reproducible across laptops, CI, and release builds.

| Artifact | Package manager | |----------|-----------------| | `package-lock.json` | npm | | `pnpm-lock.yaml` | pnpm | | `yarn.lock` | Yarn |

Manifest ranges (`^1.2.0`) describe intent; lockfiles describe reality. Application repos should commit lockfiles. Library packages may commit them for dev/CI while consumers resolve their own graphs.

					# CI patterns (conceptual)
npm ci
pnpm install --frozen-lockfile
yarn install --immutable
				

On interviews: why manifests alone are insufficient, how to review transitive bumps, frozen install failure modes, and security review of new packages in lockfile diffs.

Common pitfalls: casual lockfile regeneration upgrading many transitives; deleting lockfiles to "fix" conflicts; mixing managers so multiple lockfiles diverge.

The trade-off is reproducibility and auditability versus merge friction on large dependency updates.

Checklist:

• Commit application lockfiles.
• Review transitive changes in PRs.
• Use frozen/immutable install in CI.
• Regenerate lockfiles deliberately, not accidentally.