Repository navigation
[code-infra] Install pnpm over the image's copy instead of shimming it - #1832
Conversation
cimg/node runs an unpinned `npm install -g pnpm`, which lands next to the node binary. That directory is the one npm-run-path rebuilds PATH from before consulting the inherited PATH, so tools spawning `pnpm` that way reach the image's version rather than the one `packageManager` pins. publint 0.3.24 started packing through the package manager, which is how this surfaced. Remove that copy and install the pinned version with pnpm's standalone script, which pnpm now documents for CI in place of corepack. Pinning PNPM_VERSION lets pnpm skip its version switch rather than forking a second pnpm on every invocation; where no pin is in reach it falls back to switching itself.
Deploy previewBundle sizeTotal Size Change: 0B(0.00%) - Total Gzip Change: 0B(0.00%) Show details for 72 more bundles@mui/internal-docs-infra/abstractCreateDemo parsed: 0B(0.00%) gzip: 0B(0.00%) PerformanceTotal duration: 16.53 ms +0.47 ms(+2.9%) | Renders: 5 (+0) | Paint: 57.92 ms -2.97 ms(-4.9%)
6 tests within noise — details Check out the code infra dashboard for more information about this PR. |
Reading packageManager from the working directory forked the behaviour on cwd: jobs starting in a nested directory found a package.json without the field and silently installed an unpinned pnpm. Resolving from the git toplevel gives every job the same pinned version, which is what corepack did by walking up, and lets a missing field fail like a wrong one. `rm -f` of the binaries next to node already covers the directory npm-run-path probes; npm's global prefix is that same directory on cimg/node, so `npm uninstall -g` only freed an unreachable package tree at the cost of an npm start-up in every job on both executors.
Janpot
added
the
scope: code-infra
`pnpm setup` installs into PNPM_HOME and links the binaries in its `bin` subdirectory, defaulting the former to the XDG data dir. The exports written to BASH_ENV named neither: they pointed at ~/.pnpm, which nothing creates, and omitted `bin`. Every step after the install then found no pnpm on PATH. Setting PNPM_HOME before the install makes the value the exports use the same one `setup` acted on, rather than a guess made after the fact.
Revert before merging.
Revert with the orb pin.
Both existed to prove the fix on CI: cimg/node ships pnpm 11.18.0 at /usr/local/bin, which is the directory npm-run-path searches before PATH, and after this change that lookup reaches the pinned 11.22.0 instead.
TEMPORARY smoke test and orb pin included; both reverted once CI confirms.
2 participants
Alternative to #1830.
cimg/node installs an unpinned pnpm next to the node binary, and that directory is searched before PATH by anything using
npm-run-path. So publint 0.3.24, which now packs through the package manager, gets the image's pnpm rather than the pinned one, andCOREPACK_ROOTstops it correcting itself. #1830 adds a third pnpm tonode_modules/.binto win that search; this installs the pinned version into that directory instead, so the pnpm found first is the right one.Corepack goes with it, which pnpm now recommends against for CI and Node 25 no longer ships. Installing an exact version also stops pnpm forking a second pnpm on every call to switch to the one
packageManagernames, and apackageManagerthat doesn't name pnpm fails the step.Verified on CI by temporarily pointing this repo's orb at the branch and printing what a rebuilt
npm-run-pathlookup resolves to (both commits since reverted). Oncimg/node,/usr/local/bin/pnpmwas the image's 11.18.0 and is now the pinned 11.22.0; on the Playwright executor the same holds at/usr/bin. Note that CI on a branch normally loads the orb fromrefs/heads/master, so changes to this file are not otherwise exercised here.