chore: upgrade pnpm to 11.5.0 and enable trustLockfile#300
Merged
Conversation
949432e to
a4f907c
Compare
commit: |
victornguyen
approved these changes
Jun 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
trustLockfilesetting inpnpm-workspace.yamlWhy
With
minimumReleaseAgeenabled (pnpm@11 default), everypnpm installre-runs the supply-chain verification pass against all lockfile entries — not just the ones being changed. This causes unrelated packages to fail trust policy checks when updating a specific dependency.The
trustLockfilesetting (introduced in pnpm 11.3) tells pnpm to treat already-resolved lockfile entries as trusted, skipping the verification pass for them. Only newly resolved packages go through the check. This eliminates spurious trust policy failures on unrelated dependencies and reduces install time/memory usage on CI.Safety
trustLockfileonly skips the time-basedminimumReleaseAge/trustPolicyverification on already-locked entries. The following protections remain fully active regardless of this setting:integrityhash in the lockfile. A mismatch (compromised registry, MITM, re-published version) results in a hardERR_PNPM_TARBALL_INTEGRITYfailure.integrityfield are rejected at read time withERR_PNPM_MISSING_TARBALL_INTEGRITY.--frozen-lockfile— CI behavior is unchanged; the lockfile must exactly match the manifest.This means that even with
trustLockfile: true, a tampered tarball or stripped integrity field will still be caught. The only risk is if an attacker modifies the lockfile to point at a malicious version that was published more thanminimumReleaseAgeago — which requires both lockfile write access and a pre-positioned attack package. Since this is a private repository with restricted commit access, that risk is negligible.