require-lockfile accepts a parent lockfile pnpm will not use

[zkochan]

Summary

require-lockfile accepts a lockfile that pnpm will not use when working-directory names a project the workspace does not include, so the preflight passes and pnpm install --frozen-lockfile then fails with its own error.

findLockfile walks up from working-directory to GITHUB_WORKSPACE on the premise that "pnpm keeps the lockfile at the workspace root, which it finds by walking up from wherever it runs". Since pnpm/pnpm#15125 that premise holds only for a directory the workspace actually includes. A directory with a manifest of its own that no packages pattern selects is now a standalone project: pnpm stops the workspace search there, so its lockfile is its own, and the one above it is not part of the picture.

The action's fast, clear failure is what gets lost. The install was always going to fail, which is correct — that project needs a lockfile of its own now — but the job gets pnpm's message instead of the one this check exists to print.

Reproduction

repo/
  pnpm-workspace.yaml     packages: ['packages/**']
  package.json
  packages/pkg-1/package.json
  docs/package.json       ← has dependencies, matched by no pattern

pnpm install at the root writes repo/pnpm-lock.yaml and nothing under docs/.

With working-directory: docs and require-lockfile: true:

• findLockfile('repo/docs', 'repo') returns repo/pnpm-lock.yaml, so the preflight passes;

• pnpm install --frozen-lockfile run in repo/docs exits 1 with

  ERR_PNPM_NO_LOCKFILE  Cannot install with "frozen-lockfile" because pnpm-lock.yaml is absent
  

Confirmed on both released lines built from pnpm/pnpm at 34d8f1fe14 (v11 pnpm.mjs and the v12 binary).

Two ways out

Ask pnpm where it stands. pnpm root -w exits 0 and prints the workspace root's node_modules when the directory is one of the workspace's projects, and exits 1 with ERR_PNPM_NOT_IN_WORKSPACE when it is not. Both v11 and v12 behave the same. findLockfile could walk up only when that probe succeeds, and otherwise look in working-directory alone. That keeps the early, specific failure and leaves the membership rule where it belongs, in pnpm.

Or drop the preflight and let the selected pnpm report a missing lockfile. ERR_PNPM_NO_LOCKFILE arrives almost immediately for this case, so little is lost beyond the wording, and nothing in the action has to track how pnpm decides what a workspace contains.

Either way the README's parent-lockfile promise under require-lockfile needs the same qualification, and a test with a project the workspace leaves out would pin it.

---

Written by an agent (Claude Code, claude-opus-5).