Skip to content

chore(deps): pnpm 12.0.0-rc.3, measured but not recommended yet - #309

Closed
oddharsh wants to merge 1 commit into
mainfrom
chore/pnpm-12-rc
Closed

oddharsh wants to merge 1 commit into
mainfrom
chore/pnpm-12-rc

Conversation

@oddharsh

Copy link
Copy Markdown
Owner

Draft, not for merge. Everything in this repo works under pnpm 12. The one thing that doesn't is the thing that publishes the site.

What passes

check result
pnpm install --frozen-lockfile clean
contract suite 206 pass, 0 fail
pnpm run typecheck exit 0
build vs pnpm 11 baseline byte-identical, 1975 files, 0 differing

Byte-identical is the bar here for the same reason it was for bun: /a/ and /i/ are content-addressed, so one differing byte mints a new URL and orphans the committed shell dictionaries.

What doesn't

pnpm 12 prepends a --- YAML document separator to the lockfile, and pnpm 10.11.1 refuses it outright:

ERR_PNPM_BROKEN_LOCKFILE  The lockfile at ".../pnpm-lock.yaml" is broken:
expected a single document in the stream, but found more

Gotcha 29 records the Workers Builds image running pnpm 10.11.1.

The only reason production would still build is the self-switch: pnpm reads packageManager from package.json before it opens the lockfile, downloads 12.0.0-rc.3, and that binary parses its own format. Measured — global pnpm 11.20.0 in this tree now answers 12.0.0-rc.3.

So adopting this makes every production install depend on one registry fetch of an unreleased binary, with no fallback. If the build image ever runs with manage-package-manager-versions off, or that fetch fails, it is left holding a lockfile it cannot read. That's a worse failure mode than being two majors behind.

Two smaller findings

lockfileVersion stays '9.0'. The incompatibility is the document separator alone, not a schema bump. A one-line change upstream would remove the whole objection.

pnpm 12 locks the package manager itself, adding a packageManagerDependencies block with per-platform binaries and integrity hashes:

  .:
    configDependencies: {}
    packageManagerDependencies:
      pnpm:
        specifier: 12.0.0-rc.3
        version: 12.0.0-rc.3

That's a genuine improvement, and it's also what makes the lockfile self-referential.

It also ships a new supply-chain verification pass (Lockfile passes supply-chain policies (321 entries)), and, pleasingly, this repo's own minimumReleaseAge: 1440 initially blocked fetching rc.3 for being 30 minutes too young — gotcha 29's policy working as designed.

Recommendation

Wait for 12 GA, then re-run this branch and confirm the build image can read what it writes. Bumping to 11.21.0 in the meantime is the free move; that's GA and one patch ahead of the current pin.

🤖 Generated with Claude Code

@cloudflare-workers-and-pages

cloudflare-workers-and-pages Bot commented Aug 10, 2026 •

Copy link
Copy Markdown

Deploying with  Cloudflare Workers  Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status Name Latest Commit Updated (UTC)
❌ Deployment failed
View logs
aadhar-sh 3e511d1 Aug 11 2026, 10:29 AM

@github-actions

github-actions Bot commented Aug 10, 2026 •

Copy link
Copy Markdown
Contributor

Wire-size diff vs merge base

d98bcc4 → 80b74bf

Brotli q11, the quality the edge serves. Every number here is deterministic:
an unchanged file produces no row. Advisory — this check fails on nothing.

Client assets

No change. 12 files, 60.97 KiB Brotli total.

Pages

No change. 46 files, 476.77 KiB Brotli total.

Worker bundle

No change. 269.18 KiB gzip.

Dictionary deltas (pd/)

No change. 134 deltas, 405.30 KiB total.

oddharsh added a commit that referenced this pull request Aug 10, 2026
The bump is free: `packageManager` only, no lockfile byte changes, no build
byte changes, `--frozen-lockfile` is a no-op, 206/206, typecheck 0.

Gotcha 30 records why 12 is not the answer yet, measured against 12.0.0-rc.3
on the branch behind #309. Everything here works under it, including a
byte-identical build across all 1975 files. What does not work is pnpm
10.11.1 — the version gotcha 29 records the Workers Builds image running —
reading the lockfile pnpm 12 writes:

  ERR_PNPM_BROKEN_LOCKFILE  the lockfile is broken: expected a single
  document in the stream, but found more

It is a `---` YAML document separator, and `lockfileVersion` stays '9.0', so
one upstream line could retire the whole objection. Production would still
build only because pnpm reads `packageManager` before it opens the lockfile
and downloads the pinned binary, which parses its own format. That makes every
production install depend on a single registry fetch with no fallback, and
being two majors behind is the milder failure.

The rule worth keeping past this instance: check that the BUILD IMAGE can read
what your package manager WRITES, not just that your own install works. A
lockfile is an interchange format between two machines on different versions,
and "it installs here" tests one of them.

Co-authored-by: Aadharsh Pannirselvam <19518661+oddharsh@users.noreply.github.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
DRAFT. Everything in this repo works under pnpm 12, and the one thing that
does not is the thing that publishes the site.

What passes: `--frozen-lockfile` installs clean, 206/206 contract tests,
typecheck exits 0, and the build is BYTE-IDENTICAL to the pnpm 11 baseline
across all 1975 files, which is the bar that matters here because /a/ and /i/
are content-addressed.

What does not: pnpm 12 prepends a `---` YAML document separator to the
lockfile, and pnpm 10.11.1 refuses it outright —

  ERR_PNPM_BROKEN_LOCKFILE  the lockfile is broken: expected a single
  document in the stream, but found more

Gotcha 29 records the Workers Builds image running pnpm 10.11.1. The only
reason production would still build is the SELF-SWITCH: pnpm reads
`packageManager` from package.json before it opens the lockfile, downloads
12.0.0-rc.3, and that binary parses its own format. Measured here — global
pnpm 11.20.0 in this tree answers `12.0.0-rc.3`.

So adopting this makes every production install depend on one registry fetch
of an unreleased binary, with no fallback: if the build image ever runs with
`manage-package-manager-versions` off, or the fetch fails, the lockfile it is
left holding is one it cannot read. That is a worse failure than being two
majors behind.

Two smaller findings. `lockfileVersion` stays '9.0', so the incompatibility is
the document separator alone rather than a schema bump. And pnpm 12 adds a
`packageManagerDependencies` block pinning the package manager itself with
per-platform binaries and integrity hashes, which is a real improvement and
is also what makes the lockfile self-referential.

Not for merge until 12 ships stable and the build image can read what it writes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.

1 participant