Will pnpm@10.14's built-in runtime installation make `actions/setup-node` unnecessary?

[marcalexiei]

Context

The recent pnpm 10.14 release introduces a new feature: devEngines.runtime,
allows declaring a JavaScript runtime (Node, Deno, Bun) in package.json.

Current recommended CI setup uses both actions/setup-node and pnpm/action-setup actions:

pnpm documentation

Use cache to reduce installation time

Code reference

on:
  - push
  - pull_request

jobs:
  cache-and-install:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - uses: pnpm/action-setup@v4
        name: Install pnpm
        with:
          version: 10
          run_install: false

      - name: Install Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'

      - name: Install dependencies
        run: pnpm install

https://github.com/pnpm/action-setup?tab=readme-ov-file#notes

This action does not setup Node.js for you, use actions/setup-node yourself.

---

Questions

Given this new capability, I’d like to know whether using actions/setup-node in GitHub Actions workflows remains necessary,
or if pnpm@10.14 can fully handle runtime provisioning for CI environments:

If devEngines.runtime is used for Node.js from pnpm, does actions/setup-node become redundant?

Currently, setup-node offers functionality beyond installing Node, e.g.,
dependency caching (cache: pnpm), and handling authenticated registries.
If I rely solely on pnpm/setup-action I am losing these capabilities
Are there any plans for pnpm/action-setup to support similar features in the future?

---

Due to the state of devEngines support in actions/setup-node (pr in review: actions/setup-node#1283)
I don't have the chance to test how they behave together.
However, I’m curious how the new devEngines.runtime capability in pnpm
may affect the role pnpm/action-setup in GitHub Actions workflows. 😅

Thanks!

[oBusk]

I came here with the same wonder. I think this action could be improved to better cover this usecase, or the documentation could be updated to reflect it at the least.

It's not only that setup-node is not necessary, it's the fact that it downloads a version of node that is not even used, since any pnpm spawned node will use the node installed locally by pnpm.

For now, I've managed to get workflows working like so;

name: build
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: pnpm/action-setup@v4
        with:
          standalone: true
          run_install: false
      - uses: actions/cache@v4
        with:
          path: ~/setup-pnpm/node_modules/.bin/store/v10
          key: pnpm-store-${{ runner.os}}-${{ hashFiles('**/pnpm-lock.yaml') }}
          restore-keys: |
            pnpm-store-${{ runner.os }}-*
      - run: pnpm install --frozen-lockfile
      - run: pnpm run build
      - run: pnpm store prune

It's worth noting that if you have the engine might still warn you since pnpm is started with whatever node version it comes bundled with, I assume. But any actual script will run with devEngine.runtime.

Also note that I run pnpm store prune as a separate step, eventhough this action will prune the store as a post action. That post action will run after any cache is stored, so will not help, unfortunately. See #185

I think this action could be improved to include built-in caching of pnpm-store since you don't need to use action/setup-node anymore. That would also make run_install a lot more useful. The documentation could also be improved to suggest this usecase.