Bug: Different devEngines.packageManager.version in repo root vs working-directory breaks setup
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 86/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- github-actions, typescript
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.
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.
- Dominant language
- TypeScript
- Stars
- 140
- Forks
- 19
- Avg merge
- 7d 9h
- Merged PRs (30d)
- 8
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.
More from pnpm/setup
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug clawsweeper:linked-pr-open clawsweeper:needs-live-repro clawsweeper:no-new-fix-pr impact:message-loss issue-rating: 🐚 platinum hermit P2 regression
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
calcite-components needs triage refactor
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Esri/calcite-design-system#15203 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
danielmiessler/LifeOS#2218 ·