Prune as the post action is not useful

[oBusk]

The action will run pnpm store prune as a post action, but based on the documented example for caching as in README:

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

The caching step in the post step of action/setup-node will actually happen before the post step pnpm/action-setup which does the pruning, so the cache will not be pruned.

If you try to still benefit from the pruning in this aciton, and put any caching before pnpm/action-setup (so that the post caching happens after action-setup post), you won't benefit from the cache as the install step of this action nukes the install directory. Doing caching before pnpm is installed also means that you cannot get pnpm store path to get what directory to cache.

Workaround

To cache the pnpm store, after pruning, you could something like this

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

      - name: Get pnpm cache directory
        id: pnpm-store-path
        run: echo "path=$(pnpm store path)" >> $GITHUB_OUTPUT

      - name: Cache pnpm store
        uses: actions/cache@v4
        with:
          path: ${{ steps.pnpm-store-path.outputs.path }}
          key: ${{ runner.os }}-pnpm-store-${{ hashFiles('**/pnpm-lock.yaml') }}
          restore-keys: |
            ${{ runner.os }}-pnpm-store-

      - name: Install dependencies
        run: pnpm install

      - name: Prune store
        run: pnpm store prune

Suggestion

I think it would be great if pnpm/action-setup had built-in cache, especially since with the devEngines.runtime support, you don't really need to use setup-node anymore. That seems like quite the effort, and not sure something I could pull off, so what's easier to achieve would be to remove the pruning from the post action, and update the documentation to recommend to run it separately. I will try to see if I can put together a PR with this.

EDIT: Or, the pruning could happen right after install I guess! That should not have any negative effect on any following actions, but any caching that may happen later will be caching a pruned store at least?

[KSXGitHub]

you won't benefit from the cache as the install step of this action nukes the install directory

I haven't touched this code in a long time, but I think dest is the files of pnpm itself (pnpm.cjs and stuffs necessary to execute pnpm itself), not the store nor the cache. The store and cache should remain in ~/.local/share/pnpm/store and ~/.cache/pnpm respectively.

Personally though, I've never cache the pnpm cache, only the store.

Regarding the store prune post-action, it was implemented long ago when we still rely on actions/cache to do caching. My personal workflow still use it to this day. So I was unaware whether store prune works well with the cache of actions/setup-node.

[oBusk]

@KSXGitHub I don't know if the default store path has changed in some recent version of pnpm, but the default store is inside dest with pnpm/action-setup@4.2.0 and pnpm@10.24.0

This means that

• Using action/cache before pnpm/action-setup will give no value (as what you restored from cache is cleared)
• Using action/cache after pnpm/action-setup { run_install: true } will restore the cache to late to provide any value
• Using pnpm/action-setup { run_install: false } disables the pruning.

I guess it could be used if you use action/cache before pnpm/action-setup { run_install: true } if you use env var to set store location to be somewhere else than default.

[KSXGitHub]

That's surprising. I don't think pnpm is executed with any special environment variables. Does GitHub have any preset config by default? What is the result of pnpm config list --json and pnpm config list --json --global?

[KSXGitHub]

OK. I think I know why:

action-setup/src/install-pnpm/run.ts

Line 47 in 41ff726

exportVariable('PNPM_HOME', pnpmHome)

[KSXGitHub]

There's a few solutions to this problem:

1. Stop defining PNPM_HOME. This would be a breaking change for workflows that rely on PNPM_HOME.
2. Explicitly specify both pnpm_config_store_dir and npm_config_store_dir to work with different versions of pnpm.
3. Write a custom config to both global rc and global config.yaml to work with different versions of pnpm.
4. Can the removal of dest be tweaked or removed?

   action-setup/src/install-pnpm/run.ts

   Line 16 in 41ff726

   await rm(dest, { recursive: true, force: true })

What do you think, @zkochan?

There is already a PR that implements caching, but the cache feature shouldn't be the only way to fix this.

---

This issue also highlights the inherent flaws in the current ways of testing the action. I'm thinking that maybe we can write test code with act.

[zkochan]

I am not sure I understand the issue. pnpm store prune is reading the store location from node_modules/.modules.yaml. It should work already. Running prune immediately after install sounds good to me.

[KSXGitHub]

I am not sure I understand the issue. pnpm store prune is reading the store location from node_modules/.modules.yaml. It should work already. Running prune immediately after install sounds good to me.

The issue is that store prune is a post-action that would only occur after the cache upload (setup-node's post-action).