pnpm 10.33.2 / dependency integrity

Does frozen really stop a stale lockfile?

We copied the real package manifest and lockfile into an isolated temporary project, ran an offline frozen install, then changed the manifest without updating the lockfile and ran the same command again.

Observed verdictPASS

The matching pair installed successfully from a warm offline store. The synthetic mismatch failed with the explicit pnpm frozen-lockfile error. That protects this release workflow from silently drifting past its committed dependency graph.

Question and method

One command, two manifest states.

The first case keeps the copied manifest and lockfile untouched. The second adds a clearly synthetic dependency to the temporary manifest only. Both cases run offline with lifecycle scripts disabled, so the observed difference comes from lockfile consistency rather than network availability or package scripts.

corepack pnpm install --frozen-lockfile --offline --ignore-scripts

Locked environment

pnpm10.33.2

Nodev24.15.0

Platformwin32 / x64

NetworkOffline

Observed result

Positive case

Matching manifest accepted

Exit: 0
Elapsed: 10363 ms

Negative case

Stale lockfile rejected

Exit: 1
Error: ERR_PNPM_OUTDATED_LOCKFILE
Elapsed: 1020 ms

Matching manifest acceptedPASS
Mismatched manifest rejectedPASS
Explicit frozen-lockfile errorPASS

Limits

Integrity result, not an install-speed contest.

The positive run uses a warm local pnpm store and does not measure network or cold-cache installation.
The fixture uses this repository's dependency graph; other workspaces and peer-dependency layouts may behave differently.
Timing is diagnostic for this run only. The durable result is acceptance of the matching manifest and rejection of the mismatch.

Reproduce

The runner creates and removes its own temporary fixture. It does not edit the repository manifest or lockfile.

corepack pnpm field-test:pnpm:capture

Inspect the runner Read FT-01