Repository navigation
Conversation
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ❌ Deployment failed View logs |
aadhar-sh | 3e511d1 | Aug 11 2026, 10:29 AM |
Contributor
Wire-size diff vs merge base
Brotli q11, the quality the edge serves. Every number here is deterministic: Client assetsNo change. 12 files, 60.97 KiB Brotli total. PagesNo change. 46 files, 476.77 KiB Brotli total. Worker bundleNo change. 269.18 KiB gzip. Dictionary deltas (
|
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>
oddharsh
force-pushed
the
chore/pnpm-12-rc
branch
from
August 11, 2026 10:29
cd1842c to
3e511d1
Compare
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.
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
pnpm install --frozen-lockfilepnpm run typecheckByte-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: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
packageManagerfrom 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 answers12.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-versionsoff, 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
lockfileVersionstays'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
packageManagerDependenciesblock with per-platform binaries and integrity hashes: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 ownminimumReleaseAge: 1440initially 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