chore: adopt pnpm 10 and let packageManager name the version - #449
Merged
Conversation
The lockfile has been generated by pnpm 10 for some time while
`packageManager` still pinned 9.15.0, which Vercel reported on every build:
Detected `pnpm-lock.yaml` version 9 generated by pnpm@10.x with
package.json#packageManager pnpm@9.15.0
`packageManager` now names 10.34.5. Nothing had to be migrated to get there:
lockfileVersion 9.0 is what both majors write, so the lockfile is untouched by
this change.
The workflows stop pinning a version of their own. `pnpm/action-setup` reads
`packageManager` when no `version` is given, so the field is the single source
the way `.nvmrc` already is for Node — three copies of `9.15.0` were three
more places for the same drift to start, and this is the drift they would have
produced.
pnpm 10 runs no dependency's build script unless it is named in
`onlyBuiltDependencies`, and none here needs naming. It reports six ignored:
the four esbuild copies ship a binary per platform rather than fetching one in
a script, core-js only prints a funding notice, and electron-winstaller builds
the Windows installer this project never makes. The desktop build and the full
suite both run against that install, so the default stays and every script
stays blocked, which is the whole point of pnpm's policy.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
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
1 participant
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.
The drift
The lockfile has been generated by pnpm 10 for some time while
packageManagerstill pinned9.15.0. Vercel reported it on every build:Same class as the Node majors: several places naming a version, one of them stale, nothing failing.
What changed
packageManager→pnpm@10.34.5.version: 9.15.0.pnpm/action-setupreadspackageManagerwhen given noversion, so the field becomes the single source the way.nvmrcalready is for Node. Three copies of a version string were three more places for this exact drift to start.No lockfile migration was needed.
lockfileVersion: '9.0'is what both majors write, sopnpm-lock.yamlis byte-identical after a full pnpm 10 install — which is also the evidence the lockfile really was already pnpm-10-generated.pnpm 10's breaking change, and why nothing needed allowlisting
pnpm 10 runs no dependency's build script unless named in
onlyBuiltDependencies. It reports six ignored here, and each was checked rather than assumed:esbuild×4esbuild --version→0.28.2, and the desktop build runs.core-jselectron-winstallerSo
pnpm-workspace.yamlis untouched and every dependency script stays blocked, which is the point of pnpm's policy.I did first add a
macos-aliasentry, for the native addonds-storereached in the legacy packager DMG path — then dropped it: that path (apps/desktop/scripts/release.mjs) has since been removed in favour of electron-builder, andds-store/macos-aliasare no longer in the lockfile at all. Allowlisting a package that isn't in the tree would have been dead config.Verification
node_modules, then./scripts/check.sh→ exit 0, 24 suites clean.pnpm --filter @luke/desktop run buildsucceeds — the esbuild-driven path, which is what the unapproved esbuild scripts would have broken.pnpmto 10.34.5 from the field, so a contributor with an older pnpm onPATHis switched automatically rather than left on 9.Portable-only change; no macOS or UI surface touched, so no visual evidence applies. CI's macOS job exercises
verify.shagainst the pnpm 10 install.Pre-existing flakiness, unrelated to this change
apps/desktop's native/Electron-adjacent tests (talk-key,output-volume,apple-calendar,settings-handler,dock-presence,microphone-route,hotkey-registrar) intermittently fail undercheck.sh's parallel load with a bare'test failed'and uniform sub-second durations — the signature of a helper timeout. They pass 734/734 run alone and 34/34 in isolation, and this reproduced on pnpm 9 before any change in this branch. Flagging it as worth a look on its own; not addressed here.🤖 Generated with Claude Code
Automated visual evidence
Download the deterministic macOS evidence · workflow run
4da7647c64b1ac3236c97f9c66e5aebbd6acf719smoke