* chore(workflows): adding pr-check.yaml to validate dist/index.js

Signed-off-by: axel7083 <[email protected]>

* fix: update dist/index.js

Signed-off-by: axel7083 <[email protected]>

---------

Signed-off-by: axel7083 <[email protected]>

* 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 <[email protected]>

* 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 <[email protected]>

* 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 <[email protected]>

* 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 <[email protected]>

* 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 <[email protected]>

* 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 <[email protected]>

* 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 <[email protected]>

* 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 <[email protected]>

* 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 <[email protected]>

* 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 <[email protected]>

* 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 <[email protected]>

* 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) <[email protected]>

* 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) <[email protected]>

* fix pnpm-workspace.yaml

---------

Co-authored-by: Claude Opus 4.6 <[email protected]>

…ing undefined (#216)

When packageManager is set to e.g. "[email protected]+sha...", strip the
"pnpm@" prefix and any "+sha..." hash suffix so the action installs
the correct version. Previously returning undefined caused failures
on Windows.

* 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 <[email protected]>

* 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 <[email protected]>

* 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.

Add `pnpm run update-bootstrap [version]` to regenerate the bootstrap
lockfiles. Bumps from 11.0.0-beta.3 to 11.0.0-beta.4-1.

Problem
pnpm self-update installs the target version to PNPM_HOME/bin/pnpm, but the bootstrap binary at PNPM_HOME/pnpm has higher PATH precedence because addPath(pnpmHome) was called after addPath(pnpmHome/bin). @actions/core's addPath prepends, so the later call wins — the bootstrap version shadows the self-updated binary.

Fix
Swap the addPath call order so PNPM_HOME/bin (where self-update puts the target binary) has higher PATH precedence. The bootstrap pnpm is invoked via absolute path, so this doesn't affect the bootstrap step.