Detect manifest and lockfile drift before release
Verify that a clean install respects the reviewed dependency graph. Record package-manager settings, workspace scope, install scripts, and unexpected lockfile changes.
A manifest describes allowed dependencies, while a lockfile records a resolution. Review both when the release process depends on repeatable installation. A developer's existing dependency directory can conceal missing declarations, obsolete packages, or installation behavior that a clean builder will expose.
The npm ci documentation states that mismatched manifest and lockfile dependencies cause failure rather than an automatic lockfile update. Other package managers have their own frozen-install behavior. Use the documented mode for the repository's selected tool.
Record the installation contract
Identify the package-manager version, workspace selection, registry configuration, and flags that affect the dependency graph. Preserve necessary configuration without committing authentication material. A lockfile alone does not capture every environmental input.
| Check | Expected evidence | Failure action |
|---|---|---|
| Manifest and lock agree | Frozen install succeeds | Review and regenerate the lock deliberately |
| Tool version is fixed | Builder reports the expected version | Correct the build environment |
| Workspace scope is known | Intended packages are selected | Fix the release command |
| Lockfile remains unchanged | Clean diff after installation | Investigate the resolver or configuration |
| Required scripts are understood | Approved build steps are recorded | Review unexpected execution |
Do not run untrusted project installation scripts merely to inspect a supplied dependency file. Use an approved isolated environment when execution is necessary.
Compare a clean result
Run the documented install in a disposable, authorized build environment with the reviewed files. Avoid using a shared developer checkout whose state another process may change. Capture the command, exit status, and resulting dependency graph.
Test a deliberate small mismatch in a separate fixture to confirm the gate really fails. A command named frozen is not useful evidence if a wrapper catches its error and continues the release.
Repair drift without hiding the cause
Determine whether a dependency declaration changed, the lockfile was omitted, or a different resolver configuration produced the graph. Regenerate with the chosen tool and review the complete dependency diff. Do not delete the lockfile as a routine way to make a failed build pass.
After repair, repeat the clean installation and targeted tests. Record intentional updates separately from incidental churn. The final check should establish that the released dependency graph follows the reviewed inputs, while leaving package authenticity, advisory applicability, and runtime behavior to their own checks.
Know which dependency risks need a fix
Check affected versions, the build and deployment evidence. Use the update checklist, or discuss the dependency risks in your application review.
Sources
- npm documentation: npm ciAccessed