Skip to content

chore: upgrade pnpm to 11.5.0 and enable trustLockfile#300

Merged
IzumiSy merged 2 commits into
mainfrom
chore/upgrade-pnpm-11.5-trust-lockfile
Jun 2, 2026
Merged

chore: upgrade pnpm to 11.5.0 and enable trustLockfile#300
IzumiSy merged 2 commits into
mainfrom
chore/upgrade-pnpm-11.5-trust-lockfile

Conversation

@IzumiSy

@IzumiSy IzumiSy commented Jun 1, 2026

Copy link
Copy Markdown
Contributor

What

  • Upgrade pnpm from 11.1.2 to 11.5.0
  • Enable the new trustLockfile setting in pnpm-workspace.yaml

Why

With minimumReleaseAge enabled (pnpm@11 default), every pnpm install re-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 trustLockfile setting (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

trustLockfile only skips the time-based minimumReleaseAge / trustPolicy verification on already-locked entries. The following protections remain fully active regardless of this setting:

  • Tarball integrity verification (pnpm@11.4+) — downloaded tarballs are always checked against the integrity hash in the lockfile. A mismatch (compromised registry, MITM, re-published version) results in a hard ERR_PNPM_TARBALL_INTEGRITY failure.
  • Missing integrity rejection (pnpm@11.4+) — lockfile entries for remote tarballs without an integrity field are rejected at read time with ERR_PNPM_MISSING_TARBALL_INTEGRITY.
  • Git commit SHA validation (pnpm@11.4+) — non-hex commit fields in git resolutions are rejected to prevent command injection.
  • --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 than minimumReleaseAge ago — 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.

@IzumiSy IzumiSy force-pushed the chore/upgrade-pnpm-11.5-trust-lockfile branch from 949432e to a4f907c Compare June 1, 2026 14:24
@IzumiSy IzumiSy self-assigned this Jun 1, 2026
@pkg-pr-new

pkg-pr-new Bot commented Jun 1, 2026

Copy link
Copy Markdown

Open in StackBlitz

npm i https://pkg.pr.new/tailor-platform/app-shell/@tailor-platform/app-shell@300
npm i https://pkg.pr.new/tailor-platform/app-shell/@tailor-platform/app-shell-sdk-plugin@300
npm i https://pkg.pr.new/tailor-platform/app-shell/@tailor-platform/app-shell-vite-plugin@300

commit: a4f907c

@IzumiSy IzumiSy requested review from a team and removed request for davedc, erickteowarang, interacsean and victornguyen June 1, 2026 14:33
@IzumiSy IzumiSy merged commit 26c4ecc into main Jun 2, 2026
5 checks passed
@IzumiSy IzumiSy deleted the chore/upgrade-pnpm-11.5-trust-lockfile branch June 2, 2026 00:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants