resolution-mode trade-off: time-based reproducibility versus highest currency for repeatable CI builds

Goal

Establish a repeatable development environment where pnpm install produces an identical pnpm-lock.yaml on every machine and in CI, regardless of when the lockfile is regenerated or which pnpm major version is used.

Constraints and uncertainty

The resolution-mode setting controls how version ranges are resolved when the lockfile is updated. time-based selects the newest version that existed at the lockfile's recorded time reference, aiming to keep a regenerated lockfile stable after newer matching versions are published. highest always picks the newest matching version, which can cause drift whenever the lockfile is rebuilt. The default resolution-mode has changed across pnpm major versions, so inheriting the default is unsafe for reproducibility. Peer-dependency settings (auto-install-peers, dedupe-peer-dependents, workspace-root peer resolution) also alter the final graph independently of resolution-mode, meaning two machines with different pnpm versions or settings can produce different lockfiles even with the same resolution-mode. --frozen-lockfile in CI only detects mismatches; it does not make resolution deterministic across pnpm versions or differing peer settings.

Questions

1. For a team that regenerates the lockfile periodically (e.g., monthly Dependabot runs), does time-based meaningfully reduce churn compared to highest, or does the lockfile's time reference still allow legitimate version advances that defeat the stability goal?
2. If lowest-direct is used to pin direct dependencies to their lowest satisfying versions, how often does it pull transitive dependencies old enough to miss security fixes, and is there a practical way to audit that risk without manual inspection?
3. Given that peer-dependency settings can change the graph without any range changes, should the project commit a .npmrc that pins both resolution-mode and the peer settings, or is a documented CI checklist sufficient?