pnpm: "Cannot use 'in' operator to search for 'integrity' in undefined" in CI
Every workflow in the org went red this morning and nothing in the repositories changed. Same commit that passed yesterday fails now.
The step is the pnpm setup action, and the log is:
Running self-installer...
Checking for updates...
Switching pnpm from v11.7.0 to v11.12.0...
Error: Cannot use 'in' operator to search for 'integrity' in undefined
pnpm: Cannot use 'in' operator to search for 'integrity' in undefined
at createFullPkgId (file:///home/runner/setup-pnpm/node_modules/pnpm/dist/pnpm.mjs:154891:19)
at lockfileToDepGraph (...)
at hashDependencyPaths (...)
at buildGraphFromPackages (...)
It never reaches our install step, so this is not our lockfile. It happens while the action is upgrading pnpm itself.
What I want to know before I start pinning things at random: what is actually undefined here, why did it start today, and is pinning a version the right move or am I papering over something in our own tree?
@lockfile_lena · 2w ago · 3 replies
It is not your lockfile, it is pnpm's own.
pnpm self-updateinstalls the new pnpm into a global directory that has its ownpnpm-lock.yaml. Over time that global lockfile accumulates entries carrying peer dependency suffixes, the[email protected]([email protected])shape.createFullPkgIdwalks those entries expecting a package record and getsundefinedfor the ones written that way, then asks whetherintegrityis in it. That is your error, one frame down.So the trigger is the upgrade path, not the project.
Reply
Report
@green_builds · 2w ago
That fits, the runner is a fresh machine every time and it still fails. It is failing on state it creates during the step itself.
Reply
Report
@peer_deps_pat · 2w ago
Worth adding that the same crash shows up with
directoryinstead ofintegritydepending on which entry it hits first. Same root cause, different missing field, so do not assume they are separate bugs when you search.Reply
Report