`patchPnpmEnv` prepended `dest/node_modules/.bin` to PATH before
spawning `pnpm install` / `pnpm store prune`. On Windows in standalone
mode, `.bin/pnpm.cmd` is an npm-created shim that always points at the
BOOTSTRAP pnpm (currently 11.0.4) — the binary npm linked when it
installed `@pnpm/exe` into `node_modules`. The self-updated pnpm
written by `pnpm self-update` lives at `$PNPM_HOME/bin`, which is
separately added to PATH via `addPath()` in install-pnpm.
When the user requested a pnpm version different from the bootstrap
under `standalone: true` on Windows, patchPnpmEnv's `.bin` entry
shadowed the self-updated `$PNPM_HOME/bin` and the action's internal
`pnpm install` ran on the bootstrap. On a pnpm 11.0.x bootstrap this
broke any 11.1+ install flag (e.g. `--no-runtime`), reporting:
ERROR Unknown option: 'runtime'
POSIX standalone got lucky because `.bin` and `$PNPM_HOME` resolve to
the same directory there. Non-standalone never tripped on this since
the `.bin/pnpm` symlink for a regular `pnpm` package keeps working
across self-updates.
Removed `patchPnpmEnv` and the now-empty `src/utils/` module.
`spawnSync` now inherits `process.env`, whose PATH is already
correctly fronted by `$PNPM_HOME/bin` and `$PNPM_HOME` via the
`addPath` calls in install-pnpm.
Added `standalone_windows_self_update` to test.yaml as a regression
guard: standalone on Windows + target 11.1.0 + `run_install` with
`--no-runtime`. With the previous code, the install would have run
under the bootstrap (11.0.4) and errored on the unknown flag.
Originally found while building pnpm/setup (the new combined
pnpm + runtime action).
* fix: self-update bootstrap to packageManager-pinned version (#233)
When package.json pins pnpm via `packageManager` or an exact
`devEngines.packageManager.version`, self-update the bootstrap up
front. The bootstrap's `pnpm store path` skips pnpm's auto-switch
(the `store` command sets `skipPackageManagerCheck = true`), so it
reports the bootstrap's `STORE_VERSION` while the user's actual
install runs under the pinned version and writes to a different
STORE_VERSION — breaking `cache: true` and `setup-node`'s
`cache: pnpm` on cold caches.
* fix: check bin/ dir instead of pnpm.exe for self-update detection
On Windows pnpm self-update writes `.bin/bin/pnpm` (a JS launcher),
not `.bin/bin/pnpm.exe`, so the previous existsSync probe always
fell back to pnpmHome and the bin_dest output pointed at the
bootstrap pnpm. Check whether the `bin` directory itself exists.
* fix: self-update accepts ranges; drop exact-semver gate
`pnpm self-update` resolves semver ranges to a specific version, so
`devEngines.packageManager.version: ">=10 <11"` can also go through
the self-update path. That makes readTargetVersion total — it always
returns a string or throws — so the runtime auto-switch fallback (and
the `pnpm_config_pm_on_fail=download` export from #252) is no longer
reachable and gets removed.
Adds a range case to the cache_store_path matrix.
## Summary
- Export `pnpm_config_pm_on_fail=download` from the action so the bootstrap pnpm switches versions via `manage-package-manager-versions` instead of throwing `BAD_PM_VERSION` when a project pins `devEngines.packageManager.onFail = "error"` without supplying a `version:` input.
- Adds a `test_dev_engines_on_fail_error` workflow job (Linux/macOS/Windows, exact + range) that reproduces #252.
Fixes#252.
* fix: bin_dest output points to self-updated pnpm, not bootstrap (#247)
`pnpm self-update <version>` writes the target binary to
`${PNPM_HOME}/bin/`, leaving the bootstrap symlink at `${PNPM_HOME}/pnpm`
untouched. The `bin_dest` output was set to `${PNPM_HOME}`, so consumers
invoking `${{ steps.pnpm.outputs.bin_dest }}/pnpm` got the bootstrap
version (currently 11.0.4) instead of the version they requested.
PATH lookup hid the bug: `${PNPM_HOME}/bin` was prepended ahead of
`${PNPM_HOME}`, so `pnpm` resolved from PATH was the right one. Existing
version-respect tests only checked `pnpm --version`, not `bin_dest`.
Resolve `binDest` inside `runSelfInstaller` (target lives in
`${PNPM_HOME}/bin` after self-update, otherwise stays at `${PNPM_HOME}`)
and plumb it through to `setOutputs`. Add a regression test that invokes
`${bin_dest}/pnpm --version` directly across Linux/macOS/Windows.
* test(ci): pass bin_dest via env to survive Windows backslashes
Direct GitHub-expression interpolation of `${{ steps.pnpm.outputs.bin_dest }}`
into the bash script let bash eat the backslashes in the Windows path
(`C:Usersrunneradminsetup-pnpmnode_modules.binbin/pnpm`), failing with
"No such file or directory". Forward the value via env so the path
reaches bash unmangled.
* build: rebuild dist with clean lockfile-matched deps
The existing version tests only check output format via regex, which is
why the PATH-shadowing bug (#230) slipped through — the bootstrap pnpm's
version string matched the regex just as well as the requested version.
- test_version_respects_request: runs the action with `version: 9.15.5`
and `version: 10.33.0` (both differ from the bootstrap) and asserts
that `pnpm --version` matches exactly. Regression test for #225/#230.
- test_package_manager_field: writes a `packageManager: pnpm@<v>` entry
into package.json, runs the action with no `version:` input, and
asserts exact match. Reproduces #227; currently expected to fail
since `packageManager` extraction was intentionally not added.
* fix: overwrite npm .cmd wrappers for @pnpm/exe on Windows
npm creates .cmd wrappers that invoke bin entries through `node`,
but @pnpm/exe bins are native executables, not JavaScript files.
This causes pnpm commands to silently fail on Windows.
* fix: copy pnpm.exe to .bin/ on Windows for standalone mode
The .cmd wrapper approach didn't work because CMD doesn't properly
wait for extensionless PE binaries. Instead, copy the actual .exe
(and .cmd for pnpx) from @pnpm/exe into .bin/ so PATHEXT finds
pnpm.exe directly, bypassing npm's broken node-wrapping shim.
* fix: add @pnpm/exe dir to PATH on Windows instead of .bin shims
On Windows, npm's .bin shims can't properly execute the extensionless
native binaries from @pnpm/exe. Instead of trying to fix the shims,
add the @pnpm/exe directory directly to PATH where pnpm.exe lives.
* test: validate pnpm --version output in CI
All version checks now capture output and assert it matches a semver
pattern. Previously, a silently failing pnpm (exit 0, no output)
would pass the tests.
* debug: log pnpm --version output during setup
* fix: remove duplicate addPath in setOutputs that shadowed pnpm.exe
setOutputs called addPath(node_modules/.bin) AFTER installPnpm had
already added the correct path (@pnpm/exe on Windows). Since
GITHUB_PATH entries are prepended, .bin ended up first in PATH,
causing PowerShell to find npm's broken shims instead of pnpm.exe.
* fix: add PNPM_HOME/bin to PATH on all platforms
* fix: address review feedback — PATH ordering and regex anchoring
- Swap addPath order so pnpmHome (with pnpm.exe) is prepended last
and has highest precedence over pnpmHome/bin.
- Anchor version regex with $ and allow prerelease suffixes.
* feat: read pnpm version from devEngines.packageManager field
When no version is specified in the action config or the packageManager
field of package.json, fall back to devEngines.packageManager.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* feat: skip self-update for devEngines.packageManager and add CI tests
pnpm auto-switches to the right version when devEngines.packageManager
is set, so self-update is unnecessary. This also enables range support
(e.g. ">=9.15.0") which self-update doesn't handle.
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
* feat!: replace bundled pnpm binary with npm + lockfile bootstrap
Remove the 9MB bundled pnpm.cjs/worker.js and instead use npm ci with
committed package-lock.json files (~5KB) to install a bootstrap pnpm,
which then installs the target version with integrity verification via
the project's pnpm-lock.yaml.
Also switch from ncc to esbuild and modernize to ESM.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix: bundle as CJS to support @actions/* packages
The @actions/* packages use CJS require() for Node.js builtins,
which fails with "Dynamic require of 'os' is not supported" when
bundled as ESM. Switch esbuild output to CJS format.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix: remove "type": "module" from package.json
Node.js treats dist/index.js as ESM due to "type": "module",
but the bundle uses CJS require() calls. Remove the field so
Node.js defaults to CJS for .js files.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix: remove packageManager field and fix Windows npm spawn
- Remove packageManager from package.json to avoid version conflict
when the action tests against itself (uses: ./)
- Use shell: true on Windows so spawn can find npm.cmd
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix: always use pnpm (not @pnpm/exe) for bootstrap and update lockfile
The bootstrap only needs regular pnpm to install the target package.
@pnpm/exe requires install scripts which we skip with --ignore-scripts.
Also regenerate pnpm-lock.yaml to match current package.json.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix: use --no-lockfile for target install
--lockfile-dir pointing to GITHUB_WORKSPACE causes the bootstrap pnpm
to use the project's pnpm-lock.yaml (which tracks project deps, not
pnpm itself), corrupting the install. Revert to --no-lockfile for now.
Lockfile-based integrity verification can be added when pnpm v11 has
proper support for verifying the pnpm package itself.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix: run bootstrap pnpm via node instead of bin shim
Use `node .../pnpm/bin/pnpm.cjs` to run the bootstrap pnpm, matching
the approach used by the old bundled pnpm.cjs. This avoids issues with
the .bin symlink on different platforms.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* refactor: use pnpm self-update instead of installing target separately
- Bootstrap pnpm via npm ci (verified by lockfile)
- Use `pnpm self-update <version>` for explicit version
- Let pnpm handle packageManager field automatically
- Remove standalone/exe-specific install logic (pnpm handles this)
- Update tests to not run pnpm install against the action repo itself
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* feat: support standalone mode with @pnpm/exe bootstrap
- When standalone=true, bootstrap with @pnpm/exe via npm ci
- When standalone=false, bootstrap with pnpm via npm ci
- Both use pnpm self-update to reach the target version
- Remove --ignore-scripts from npm ci so @pnpm/exe install scripts run
- Add standalone test back to CI
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* debug: add logging to diagnose pnpm not found on PATH
Log .bin directory contents after npm ci to understand why
pnpm binary is not found in subsequent CI steps.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix: ensure pnpm bin link exists after npm ci
npm ci sometimes doesn't create the .bin/pnpm symlink for
@pnpm/exe (observed on Linux CI). Manually create the symlink
if it's missing after npm ci completes.
This fixes the case where standalone=true with no explicit version
(relying on packageManager field) — pnpm self-update wouldn't run,
leaving .bin empty and pnpm not found on PATH.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix: add PNPM_HOME/bin to PATH for pnpm v11
pnpm v11 moved global binaries from PNPM_HOME to PNPM_HOME/bin.
Add the new bin subdirectory to PATH so that pnpm's global bin
directory check passes. This is backwards compatible — the extra
PATH entry is harmless for older pnpm versions.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix: add packages field to pnpm-workspace.yaml
pnpm v9 requires the packages field in pnpm-workspace.yaml.
Without it, `pnpm --version` fails with "packages field missing or empty".
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix pnpm-workspace.yaml
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
* feat: add an option to install the self-contained binary version of pnpm
* test: add a test about nodejs_bundled
* style: remove an empty line
* chore: use newer pnpm
* chore: update dependencies
* feat: rename `nodejs_bundled` to `standalone`
as @zkochan suggested
* docs: add
---------
Co-authored-by: Takashi Sato <takashi@tks.st>