Bug: Different devEngines.packageManager.version in repo root vs working-directory breaks setup
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 140
- Forks
- 19
- Avg merge
- 13h 19m
- Merged PRs (30d)
- 3
Description
Minimal bug reproduction: https://github.com/alecglassford/bug-reproduction-pnpm-setup-multiple-package-json-pnpm-versions
If you set the working-directory input, the action downloads a version of pnpm according to the devEngines.packageManager.version ("inner version") from the package.json in the working-directory. However, if there is a separate package.json with a different devEngines.packageManager.version ("outer version") at the repo root[^1], the post-download version check fails.
[^1]: Or more specifically, I think, at GITHUB_WORKSPACE — which is usually also the repo root
This occurs because, even though the pnpm executable used for the check is the inner version, pnpm --version always returns the version of the pnpm configured for the current working directory, which is the outer version.
This can lead to error like the following in logs:
Downloading pnpm 12.0.0 from the npm registry
==> Downloading pnpm 12.0.0
Error: The installed pnpm reports version 12.1.0, expected 12.0.0
(In this case the "inner version" is 12.0.0 and the "outer version" is 12.1.0.)
Suggested fix
When the action runs pnpm --version, set the cwd to the working-directory input, rather than running from the default GITHUB_WORKSPACE. I.e.
-->
const cp = spawn(pnpmBin, ['--version'], { cwd: workingDirectory, stdio: ['ignore', 'pipe', 'inherit'] })
Workaround
For my use case, it is sufficient to run rm package.json in a step before setup/node. This might also work for other users.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in src/install-pnpm/run.ts, especially the post-download version check around lines 30-35 and the pnpm --version invocation around line 117. Reproduce the mismatch with the linked repository, then verify the check uses the working-directory package configuration and no longer reports the outer version as installed; run the repository's relevant tests if available.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, typescript
- Domain
- ci-cd, devops
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 86/100