pnpm/Setup pnpm with runtime

Install pnpm and a JavaScript runtime (Node.js, Bun, or Deno) in one step

View on GitHub

Trust Signals

Scorecard Score
not yet scored
Maintenance Recency
Stale
License
None
namedescriptionrequireddefault
versionVersion of pnpm to installno
destWhere to store pnpm filesno~/setup-pnpm
runtimeRuntime to install, in `<name>` or `<name>@<version>` form (matching pnpm's `packageManager` field syntax). Supported names: `node`, `bun`, `deno`. Examples: `node@22`, `node@lts`, `node@^24.4.0`, `bun@latest`, `deno@2`. When the version is omitted, the action falls back to the version declared in `devEngines.runtime` for the same name, or to `lts` (for `node`) / `latest` for others. If this input is omitted entirely, the action reads `devEngines.runtime` from the project's package.json. If that is also missing, no runtime is installed. no
cacheWhether to cache the pnpm store directorynofalse
cache-dependency-pathFile path to the pnpm lockfile, which contents hash will be used as a cache keynopnpm-lock.yaml
package-json-fileFile path to the package.json to read `packageManager` and `devEngines.runtime` configuration. This path must be relative to the repository root (GITHUB_WORKSPACE).nopackage.json
installWhether to run `pnpm install` after pnpm and the runtime are set up. When set to `true` (the default), the action runs `pnpm install` in the workspace when a package.json is present. When the `runtime` input is also set, `--no-runtime` is appended automatically so the installed runtime isn't shadowed by a different version declared in `devEngines.runtime`. Set to `false` to skip the install step — useful for jobs that only need pnpm itself (e.g. `pnpm audit`, lockfile-only regeneration). notrue
namedescription
destExpanded path of inputs#dest
bin-destLocation of `pnpm` and `pnpx` command
runtime-nameName of the installed runtime (`node`, `bun`, or `deno`), or empty if none was installed
runtime-versionResolved version of the installed runtime, or empty if none was installed