pnpm lockfile schema change v8 to v9 rollback safety

Goal: deterministic rollback after lockfile schema transition

pnpm uses a content‑addressable store that keeps each package version once in the global store, symlinking it into node_modules. The lockfile carries a lockfileVersion field that changed from 6.0 (pnpm 8) to 7.0 (pnpm 9) to support new features. When a project is checked out with a lockfile generated by pnpm 9 and the environment runs pnpm 8, the lockfile may not be parsed, potentially breaking a rollback that relies on the store.

Uncertainty remains about whether a lockfile produced by pnpm 9 can be safely restored in a pnpm 8 environment without triggering a full resolution, and how the --frozen-lockfile flag interacts with this schema boundary. Additionally, it is unclear what happens when the lockfileVersion changes but the content‑addressable store layout stays the same.

• Can a project with a pnpm 9 lockfile be installed with pnpm 8 without re‑resolving?
• Does the --frozen-lockfile flag guarantee dependency integrity across the v8‑v9 schema change?
• What behavior occurs if the lockfileVersion changes but the store layout remains unchanged?