A package manifest expresses intended dependencies; a lockfile records the resolved graph and integrity metadata for an install. A clean-install command checks the manifest against that lock and refuses to rewrite it when they disagree. This makes dependency resolution repeatable within the same package manager and configuration. It does not prove that every package is safe, that install scripts are harmless, or that two operating systems emit identical bundles. Track the toolchain and install flags alongside the lockfile.
Locked Dependency Resolution and Clean Installs
Working case
A case dashboard build passes on a developer laptop but fails in release validation after a transitive parser update. The team commits the lockfile with the manifest and pins the package manager version used by CI. A new dependency request changes both files in one reviewed change, with a recorded reason and bundle impact. The release job uses a clean install and rejects a manifest-only edit. Reviewer 47 sees the same dashboard behavior in staging that was tested for case 62, rather than a package graph resolved hours later from a broad version range.
Implementation boundary
function lockMatchesManifest(manifest, lock) {
return Object.entries(manifest.dependencies).every(([name, range]) => lock.packages[name]?.requested === range);
}
console.log(lockMatchesManifest({ dependencies: { 'case-parser': '^4.7.0' } }, { packages: { 'case-parser': { requested: '^4.6.0' } } }));
// Output: falseCommit the manifest and lockfile together. In CI, use the package manager's frozen or clean-install mode with a pinned toolchain and the same relevant configuration as development. Check that the selected workspace and optional dependencies match the target deployment. Maintain a short update window: propose version changes, inspect transitive movement, run affected tests, and record any exception. Do not edit lockfile integrity fields by hand or rely on a locally cached node_modules directory as release evidence. Store the resolved graph digest with the build record so an incident can identify which packages actually reached a release.
Cost and boundaries
A clean install often downloads more than an incremental developer install, but it removes hidden local state from release validation. Caching package archives can reduce time without caching an unverified installed tree. The lockfile can be large; review tooling should highlight added packages, lifecycle scripts, license changes, and unexpected registries instead of asking reviewers to read every hash. Hashing the manifest and lockfile is O(file size); resolving and installing the graph is dominated by package count, archive transfer, and filesystem work.
Failure trace
A release job runs a non-frozen install and silently rewrites the lockfile before bundling. The source commit no longer describes the deployed graph. Another job pins package versions but uses a different install flag, changing peer resolution. Reproduce a manifest-lock mismatch and require the job to fail before the build starts. Test a cold cache, a corrupted archive, a missing optional dependency on the target platform, and a new package with an install script. Each outcome needs an explicit failure or reviewed exception, never a quiet fallback to an unrecorded graph.
Verification
- A manifest-lock mismatch fails before bundling.
- Build records include package-manager version and graph digest.
- Cold-cache release installation follows the same locked graph.
Practice drill
Change the declared parser range without updating the lockfile and run the release install; it should stop. Then update the lock in a separate review and compare added packages, scripts, and output size. Build from two clean workspaces with the same toolchain and configuration, compare artifact manifests, and explain any byte difference. Record a rollback target with its dependency graph digest rather than only the branch name.
Decision note
A lockfile fixes resolution for review; release evidence also includes toolchain, configuration, and emitted artifacts.
Common Mistakes
- Treating a lockfile as a safety audit.
- Reusing an unexplained local installed tree for a release.
- Updating the manifest while leaving the lockfile stale.
Connected lessons
Build Project: frontend artifact promotion and rollback and review Web Development: embedded interfaces and build integrity quiz; follow Frontend Build and Artifact Integrity; Dependency Admission, Install Scripts, and Provenance; External Asset Integrity and Module Resolution; Artifact Manifest, Rollout, and Rollback Coherence; Continuous Integration and Release Gates; Dependency Integrity and Update Window.
