developersIO
How to Fix the "Cannot use 'in' operator" Error in pnpm/action-setup@v6

How to Fix the "Cannot use 'in' operator" Error in pnpm/action-setup@v6

Fixing the "Cannot use 'in' operator" error when using pnpm/action-setup@v6 in GitHub Actions: the risks of version: latest and how to pin the version with the packageManager field.
GitHub ActionsCI/CD
lin-yuchen
2026.07.14

This page has been translated by machine translation. View original

Introduction

While using pnpm/action-setup@v6 in a GitHub Actions CI workflow, all jobs suddenly started failing one day with the following error.

[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 (file:///home/runner/setup-pnpm/node_modules/pnpm/dist/pnpm.mjs:154840:20)
    ...
##[error]Something went wrong, self-installer exits with code 1

The CI broke even though I hadn't changed any code, and the cause was the version: latest setting of pnpm/action-setup@v6.

Cause

The workflow was configured as follows.

.github/workflows/ci.yml
- uses: pnpm/action-setup@v6
  with:
    version: latest

version: latest installs the latest version of pnpm at the time of execution. pnpm/action-setup@v6 works by upgrading the pnpm preinstalled in the runner environment to the latest version, and a crash occurred when this upgrade process (the self-installer) processed its internal lockfile.

Switching pnpm from v11.7.0 to v11.12.0...
[ERROR] Cannot use 'in' operator to search for 'integrity' in undefined

The createFullPkgId → lockfileToDepGraph in the stack trace is an error where the code tries to read the resolution field from a lockfile package snapshot and accesses undefined. This is a regression introduced in pnpm v11.12.0 and has been reported as pnpm/action-setup#276 (still open as of July 12, 2026).

When action-setup self-updates the old pnpm on the runner to v11.12.0, it hits a new bug in the lockfile parsing code and crashes.

Solution: Pin the version with the packageManager field

Remove version: latest and instead explicitly specify the pnpm version in the packageManager field of package.json.

package.json:

package.json
{
  "packageManager": "pnpm@11.3.0"
}

CI workflow:

.github/workflows/ci.yml
- uses: pnpm/action-setup@v6
# No version specified — automatically refers to the packageManager field in package.json

If the version parameter is omitted, pnpm/action-setup@v6 automatically reads the version from the packageManager field in package.json.

Why this method is best

Method Pros Cons
version: latest Always the latest CI breaks due to unexpected breaking changes
version: "11.3.0" (pinned in CI) Stable Local and CI tend to end up with different versions
packageManager field Everyone—local, CI, and team members—uses the same version package.json needs to be updated when upgrading versions

The approach of using the packageManager field offers:

  • Single Source of Truth: The version definition is consolidated in a single place in package.json
  • Consistency between local and CI: Since Corepack (when enabled) and pnpm itself refer to this field, versions are aligned across developers
  • Compatibility with Dependabot: pnpm version updates can also be automated via Dependabot PRs

Notes

  • The packageManager field requires a full version (ranges such as ^11.0.0 are not allowed)
  • If both the version parameter and the packageManager field exist, pnpm/action-setup@v6 gives priority to the version parameter
  • With Node.js 16 or later, Corepack recognizes this field, and after corepack enable the version is enforced locally as well

Summary

  • Using version: latest with pnpm/action-setup@v6 carries the risk that CI will suddenly break due to a bug in a new pnpm version
  • The best practice is to pin the version with the packageManager field in package.json and remove the version parameter from the CI side
  • There is a bug in the self-installer of pnpm v11.12.0 that causes the Cannot use 'in' operator error in GitHub Actions environments (as of July 2026)

Share this article