v5 fails immediately when using `pnpm`

[peterhirn]

Description: I'm using corepack to install pnpm. Using v5 the action fails immediately, afaict doesn't even make it to the corepack step.

Action version: v5

Platform:

• [x] Ubuntu
• [ ] macOS
• [ ] Windows

Runner type:

• [x] Hosted
• [ ] Self-hosted

Tools version:

  "engines": {
    "node": "24.7.0"
  },
  "packageManager": "[email protected]+sha512.34e538c329b5553014ca8e8f4535997f96180a1d0f614339357449935350d924e22f8614682191264ec33d1462ac21561aff97f6bb18065351c162c7e8f6de67"

Repro steps:

name: restore

runs:
  using: composite
  steps:
    - name: Install Node.js
      #uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4
      uses: actions/setup-node@a0853c24544627f65ddf259abe73b1d18a591444 # v5
      with:
        node-version-file: package.json

    - name: Install pnpm
      shell: bash
      run: |
        corepack enable
        corepack prepare --activate

    - name: Export pnpm store path
      shell: bash
      run: |
        echo "STORE_PATH=$(pnpm store path --silent)" >> $GITHUB_ENV

    - name: Setup pnpm cache
      uses: actions/cache@0400d5f644dc74513175e3cd8d07132dd4860809 # v4
      with:
        path: ${{ env.STORE_PATH }}
        key: ${{ runner.os }}-pnpm-store-${{ hashFiles('pnpm-lock.yaml') }}
        restore-keys: |
          ${{ runner.os }}-pnpm-store-

    - name: Install dependencies
      shell: bash
      run: pnpm install --frozen-lockfile

    - name: Store prune
      shell: bash
      run: pnpm store prune

Prepare all required actions
Getting action download info
Download action repository 'actions/setup-node@a0853c24544627f65ddf259abe73b1d18a591444' (SHA:a0853c24544627f65ddf259abe73b1d18a591444)
Download action repository 'actions/cache@0400d5f644dc74513175e3cd8d07132dd4860809' (SHA:0400d5f644dc74513175e3cd8d07132dd4860809)
Run ./.github/actions/restore
Run actions/setup-node@a0853c24544627f65ddf259abe73b1d18a591444
  with:
    node-version-file: package.json
    always-auth: false
    check-latest: false
    token: ***
    package-manager-cache: true
Resolved package.json as 24.7.0
Attempting to download 24.7.0...
(node:1991) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
Acquiring 24.7.0 - x64 from https://github.com/actions/node-versions/releases/download/24.7.0-17283839804/node-24.7.0-linux-x64.tar.gz
Extracting ...
/usr/bin/tar xz --strip 1 --warning=no-unknown-keyword --overwrite -C /home/runner/work/_temp/32676364-91bc-4278-a2bc-700823b9c0d4 -f /home/runner/work/_temp/96a07732-bdfd-4e82-a07c-8a2a6550709e
Adding to the cache ...
Environment details
  node: v24.7.0
  npm: 11.5.1
  yarn: 1.22.22
Error: Unable to locate executable file: pnpm. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also check the file mode to verify the file is executable.

Expected behavior:

Using v4 everything works as expected:

Prepare all required actions
Getting action download info
Download action repository 'actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020' (SHA:49933ea5288caeca8642d1e84afbd3f7d6820020)
Download action repository 'actions/cache@0400d5f644dc74513175e3cd8d07132dd4860809' (SHA:0400d5f644dc74513175e3cd8d07132dd4860809)
Run ./.github/actions/restore
Run actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020
Resolved package.json as 24.7.0
Attempting to download 24.7.0...
Acquiring 24.7.0 - x64 from https://github.com/actions/node-versions/releases/download/24.7.0-17283839804/node-24.7.0-linux-x64.tar.gz
Extracting ...
/usr/bin/tar xz --strip 1 --warning=no-unknown-keyword --overwrite -C /home/runner/work/_temp/5be513fa-45a1-4cbf-b962-41ec7d0b828f -f /home/runner/work/_temp/1b86ae81-2e8a-4a03-bb71-adb4c43b321f
Adding to the cache ...
Environment details
  node: v24.7.0
  npm: 11.5.1
  yarn: 1.22.22
Run corepack enable
  corepack enable
  corepack prepare --activate
  shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
Preparing [email protected]+sha512.34e538c329b5553014ca8e8f4535997f96180a1d0f614339357449935350d924e22f8614682191264ec33d1462ac21561aff97f6bb18065351c162c7e8f6de67 for immediate activation...
Run echo "STORE_PATH=$(pnpm store path --silent)" >> $GITHUB_ENV
Run actions/cache@0400d5f644dc74513175e3cd8d07132dd4860809
Cache hit for restore-key: Linux-pnpm-store-b7d2050696ee54d49a8aad9d2b825770a2ccafcb302f1fb77ebbe74d6ce0757b
Received 134217728 of 153022715 (87.7%), 120.0 MBs/sec
Received 153022715 of 153022715 (100.0%), 117.9 MBs/sec
Cache Size: ~146 MB (153022715 B)
/usr/bin/tar -xf /home/runner/work/_temp/43de40db-0b79-4b5b-b9a3-f8da86ea6973/cache.tzst -P -C /home/runner/work/website/website --use-compress-program unzstd
Cache restored successfully
Cache restored from key: Linux-pnpm-store-b7d2050696ee54d49a8aad9d2b825770a2ccafcb302f1fb77ebbe74d6ce0757b
Run pnpm install --frozen-lockfile
Lockfile is up to date, resolution step is skipped
Progress: resolved 1, reused 0, downloaded 0, added 0
Packages: +810
...

Actual behavior: Action fails immediately.

[aparnajyothi-y]

Hello @peterhirn, Thank youf or creating this issue and we will look into it :)

[Eynorey]

Same issue, this action has never supported Corepack, and it's getting more and more cumbersome to use. Unless https://github.com/actions/setup-node/issues/531 gains some traction, it might finally be time to look for or build an alternative...

It's a chicken-egg problem that has existed since caching support was introduced:

• You need PNPM to use setup-node's cache feature
• You need Node to install PNPM via Corepack

We have gotten used to solve this via a two-step approach:

- name: Install Node.js
  uses: actions/setup-node@v5
  with:
    node-version-file: .nvmrc
- name: Enable Corepack
  run: corepack enable
- name: Configure Dependency Cache
  uses: actions/setup-node@v5
  with:
    cache: pnpm

Now we need to set package-manager-cache: false in the first call so that the action works at all, even though we want to use the cache, which is super awkward.

- name: Install Node.js
  uses: actions/setup-node@v5
  with:
    node-version-file: .nvmrc
    package-manager-cache: false
- name: Enable Corepack
  run: corepack enable
- name: Configure Dependency Cache
  uses: actions/setup-node@v5
  with:
    cache: pnpm

[priyagupta108]

Hi! 👋 Thank you for sharing your workflow and describing the issue.

This behavior is expected with actions/setup-node v5. In this release, caching is automatically enabled if your package.json includes a valid packageManager field (such as pnpm, yarn, or npm). This update is aimed at simplifying dependency caching by default.

To turn off automatic caching and restore the previous behavior, set package-manager-cache: false in setup-node step:

steps:
- uses: actions/checkout@v5
- uses: actions/setup-node@v5
  with:
    package-manager-cache: false

For more information on this update and recommended configuration, please refer to:

• v5.0.0 Release Notes
• README – Caching Packages

If you have any other questions or run into any issues, feel free to ask. We're happy to help!

[notaphplover]

Hey @priyagupta108

This behavior is expected with actions/setup-node v5. In this release, caching is automatically enabled if your package.json includes a valid packageManager field (such as pnpm, yarn, or npm). This update is aimed at simplifying dependency caching by default.

If the behavior is expected, could you please tell us how to use the action with the caching feature enabled when pnpm is set as the package manager? As @Eynorey already explained, there's no way to use the action without setting package-manager-cache: false. If only you could support setting a custom package manager, then this caching feature would make sense to non npm users.

If your answer is: add package-manager-cache: false if you're not using npm, then I would suggest to try not to go that way in the future, for it would mean other package managers are becoming second class citizens. Everybody makes mistakes, I hope you keep up the great work 🙂

[tagliala]

Hello,

with this approach:

      - uses: pnpm/action-setup@v4
      - name: Set up Node
        uses: actions/setup-node@v5
        with:
          node-version: '22'
      - name: Install node dependencies
        run: pnpm install

and a committed pnpm-lock.yaml, I do not have issues with cache, setup-node@v5, and pnpm

You can take a look at a successful run here:

https://github.com/diowa/ruby3-rails7-bootstrap-heroku/actions/runs/17490730192/job/49679724339

Excerpt from logs:

Cache restored successfully
Cache restored from key: node-cache-Linux-x64-pnpm-d56c4b93812f483a78e79eb6d745119442ec1fa19155fdca871b03dff741c8f3

#...

Run pnpm install
Lockfile is up to date, resolution step is skipped
Progress: resolved 1, reused 0, downloaded 0, added 0
Packages: +910
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Progress: resolved 910, reused 910, downloaded 0, added 375
Progress: resolved 910, reused 910, downloaded 0, added 910, done
Done in 2.1s using pnpm v10.9.0

---

Note about the pnpm/action-setup: it is an official action from the pnpm team and it is the documented way of implementing pnpm in the GitHub actions pipeline

Refs:

• https://github.com/pnpm/action-setup
• https://pnpm.io/continuous-integration#github-actions

[notaphplover]

Hey @tagliala,

      - uses: pnpm/action-setup@v4
     - name: Set up Node
       uses: actions/setup-node@v5
       with:
         node-version: '22'
     - name: Install node dependencies
       run: pnpm install

Amazing. I was not aware you could set pnpm via pnpm/action-setup without setting up node. Thanks!

[alexaka1]

Same issue happens for yarn v4. error This project's package.json defines "packageManager": "[email protected]". However the current global version of Yarn is 1.22.22.

Except that yarn does not have a setup action. Not to mention the official installation method is via Corepack. https://yarnpkg.com/getting-started/install

I know, who uses Yarn anymore (insert some meme here), but it is still part of the ecosystem.

[dominikg]

edit: i missed updating the second job in the workflow, package-manager-cache: false works.

https://github.com/sveltejs/vite-plugin-svelte/pull/1213

previous comment stating the opposite

it fails even when package-manager-cache: false is set https://github.com/sveltejs/vite-plugin-svelte/pull/1213/files

note that these workflows don't use pnpms setup action but rather setup-node twice. first time it is used to be able to run npm i -g pnpm@version. And only the second time around cache is enabled. this used to work fine in v4

[tagliala]

Hello, as far as I agree that extra actions are not ideal, I would like to clarify and I will also edit my above comment, that pnpm/action-setup is an official action from the pnpm team and it is the documented way of implementing pnpm in the GitHub actions pipeline

Refs:

• https://github.com/pnpm/action-setup
• https://pnpm.io/continuous-integration#github-actions

[Julusian]

We are seeing the same issue with yarn4. Yarn is installed/setup in the recommended way, so having to manually updated the workflows to disable caching is frustrating. Especially when dependabot is happily opening PRs to update this, which will break everything if merged (I have 15 emails already)

[dominikg]

Hello, as far as I agree that extra actions are not ideal, I would like to clarify and I will also edit my above comment, that pnpm/action-setup is an official action from the pnpm team and it is the documented way of implementing pnpm in the GitHub actions pipeline

Refs:

* https://github.com/pnpm/action-setup

* https://pnpm.io/continuous-integration#github-actions

even if it is an official action, it should not be required to be able to use setup-node

The situation around yarn is even more concerning as it doesn't have an alternate way of installing it (although i believe it is still part of default runner images, but probably not in the version you'd want https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md#package-management)

[Julusian]

The situation around yarn is even more concerning as it doesn't have an alternate way of installing it (although i believe it is still part of default runner images, but probably not in the version you'd want actions/runner-images@main/images/ubuntu/Ubuntu2404-Readme.md#package-management)

Yeah, the yarn1 binaries simply check if the project is setup for yarn3+ and will fail with an error saying to use corepack. So the presence of yarn as a default binary doesnt really do any harm, but also doesnt help.

The log output that gets produced:

Run actions/setup-node@v5
Resolved .node-version as 22.11
Attempting to download 22.11...
(node:2119) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
Acquiring 22.11.0 - x64 from https://github.com/actions/node-versions/releases/download/22.11.0-11593095476/node-22.11.0-linux-x64.tar.gz
Extracting ...
/usr/bin/tar xz --strip 1 --warning=no-unknown-keyword --overwrite -C /home/runner/work/_temp/4b3f2778-6409-4be1-8dc7-ece3b4faa630 -f /home/runner/work/_temp/64397a96-7e03-4ac6-a2ed-444f93cae0a8
Adding to the cache ...
Environment details
/usr/local/bin/yarn --version
1.22.22
/usr/local/bin/yarn cache dir
error This project's package.json defines "packageManager": "[email protected]". However the current global version of Yarn is 1.22.22.

Presence of the "packageManager" field indicates that the project is meant to be used with Corepack, a tool included by default with all official Node.js distributions starting from 16.9 and 14.19.
Corepack must currently be enabled by running corepack enable in your terminal. For more information, check out https://yarnpkg.com/corepack.
Error: error This project's package.json defines "packageManager": "[email protected]". However the current global version of Yarn is 1.22.22.

Presence of the "packageManager" field indicates that the project is meant to be used with Corepack, a tool included by default with all official Node.js distributions starting from 16.9 and 14.19.
Corepack must currently be enabled by running corepack enable in your terminal. For more information, check out https://yarnpkg.com/corepack.

[dominikg]

i made a mistake above, package-manager-cache: false works and you can use it to manually install the package manager of your choice via node like this (uses pnpm but pretty sure you can use it to install yarn activate berry or whatever chants you have to cite to get it working)

      - uses: actions/checkout@v5
      - uses: actions/setup-node@v5
        with:
          package-manager-cache: false # pnpm is not installed yet
      - name: install pnpm #installs the exact pnpm version from package.json packageManager field
        shell: bash
        run: |
          PNPM_VER=$(jq -r '.packageManager | if .[0:5] == "pnpm@" then .[5:] else "packageManager in package.json does not start with pnpm@\n" | halt_error(1)  end' package.json)
          echo installing pnpm version $PNPM_VER
          npm i -g pnpm@$PNPM_VER
      - uses: actions/setup-node@v5
        with:
          package-manager-cache: true # caches pnpm via packageManager field in package.json
      - name: install
        run: pnpm install --frozen-lockfile --prefer-offline --ignore-scripts

[jakebailey]

Every repo I have that uses pnpm is breaking because of this; it seems odd that a feature that is designed to check packageManager doesn't work if it's set? I also suspect this doesn't work right when packageManager is set to npm, if the action is not actually setting up corepack or installing the package manager in some way...

[flcdrg]

Would be nice to see some integration tests added to this repo to exercise the action, particularly with multiple package managers. I feel like if those were in place then this change might either not have been approved or would have been done in a less breaking way.

[priyagupta108]

As @tagliala mentioned, when using pnpm caching with actions/setup-node, it’s important to ensure that pnpm is preinstalled before running the setup-node action. Please refer to the action’s documentation on pnpm caching.

To clarify, the Yarn issue is a known problem with Yarn itself and is being tracked here: yarnpkg/yarn#9015. There is also an ongoing discussion regarding this topic in actions/setup-node#1027, which you can refer to for additional context and related discussions.

Please note: If caching is not required for your use of actions/setup-node, disable automatic caching by setting package-manager-cache: false in your setup-node step.

steps:
  - uses: actions/checkout@v5
  - uses: actions/setup-node@v5
    with:
      package-manager-cache: false

[snebjorn]

Everyone, please go and 👍 this

• #531

[alexaka1]

Same issue happens for yarn v4. error This project's package.json defines "packageManager": "[email protected]". However the current global version of Yarn is 1.22.22.

Except that yarn does not have a setup action. Not to mention the official installation method is via Corepack. https://yarnpkg.com/getting-started/install

I know, who uses Yarn anymore (insert some meme here), but it is still part of the ecosystem.

I failed to mention this, as this is kind of last year's news, but Corepack will be removed in node 25 (maybe 26). Adoption was proactively killed by Node, so supporting it is also moot. Yarn needs to come up with their own distribution method. Pnpm has already done it when this was initially brought up.

My comment wasn't to criticise the lack of Corepack support, but to mention the "begging the question" behaviour of the v5 action. Trying to cache the package manager by default, but then failing for every single package manager. Thus everyone having to opt out of this, or call the action twice in a row, which is just silly. It is also a strange decision to check the packageManager property, when it was never supported by Node or NPM, this was always a Corepack thing. There is, however, the devEngines proposal, which I guess has moved past proposal since I last checked, which was accused of doing the same thing as Corepack but better, but I have not followed that thread after the execution. Tldr, I don't understand why checking the packageManager field was introduced. I also don't understand what it is caching precisely since the pnpm setup step runs before this action, so it can't read anything from cache if the manager is already downloaded from a previous step.

[jakebailey]

Trying to officially support corepack I think is fine, given the project still persists despite not being included with node anymore, but I think it's wrong to try and support packageManager directly in this action without an explicit opt-in for corepack given the above, or not using devEngines (which theoretically other tools are now supporting too, it's really just a wider spec).

Personally, I think handling of packageManager needs to be reverted, becuase it really is a corepack thing and doesn't work if you don't support corepack. It's not a generic indicator of "this is the package manager being used, so attempt to cache". It implies more setup must be done, and everyone today is doing it by hand, which is fine, but not so much if it's not also done in the action before it attempts to cache deps.

(I say this as a huge corepack fan, to be clear. I am constantly saddended by how things are going.)

[notaphplover]

Hey @priyagupta108,

As @tagliala mentioned, when using pnpm caching with actions/setup-node, it’s important to ensure that pnpm is preinstalled before running the setup-node action. Please refer to the action’s documentation on pnpm caching.

Yeah, but if caching is enabled by default, I honestly believe crashing due to a missing cache setup is a behavior with room for improvement. Wouldn't it make sense to detect whether or not package managers are installed so you can log a warning and disable cache behavior?

Example

Let's say I have a package.json with a packageManager field set to [email protected].

Let's say pnpm is not installed when actions/setup-node@v5 is used. A much gentler behavior could be:

1. The action detects pnpm as the package manager.
2. The action checks whether or not pnpm is installed. For example, if pnpm --version exits with code 0, pnpm is almost guaranteed to be installed. You can even get the version and match it against [email protected] found on package.json if you want.
3. If pnpm is not installed, emit a warning and disable actions/setup-node@v5 cache strategy.

While I agree the action is properly documented, I don't understand why is it so hard to acknowledge we can do better. I don't see a compeling reason for not changing this behavior in order to make this action easier to use for everyone.

---

Please note: If caching is not required for your use of actions/setup-node, disable automatic caching by setting package-manager-cache: false in your setup-node step.

This is the most controversial part for me. Even if we accept this is the best behavior instead of not caching by default, can't we at least warn developers about this in the logs?

Is really this error message the best one?

Error: Unable to locate executable file: pnpm. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also check the file mode to verify the file is executable.

Wouldn't it be better to face a gentler error such as

Error: Unable to locate executable file: pnpm. Please verify either pnpm is installed or disable automatic caching: https://github.com/actions/setup-node#caching-global-packages-data

[alexaka1]

Also worth noting that pnpm by default self manages its version using the packageManager field. https://pnpm.io/settings#managepackagemanagerversions It's not clear if this uses corepack under the hood (probably not).

[priyagupta108]

Thank you all for raising these points and for your thoughtful discussion. Based on your feedback and our latest updates, here are some clarifications and recommendations:

• Automatic Caching:
  Automatic caching is now enabled if no explicit cache input is provided and a valid package manager is detected (this came from the implementation of #686). The rest of the required setup remains unchanged. As requested in feature request #686, we use the packageManager field to detect the name for the cache key, but you can always override this with the cache input if your needs differ. We will also explore the possibility of supporting devEngines detection for even better compatibility in the future.

• Disabling Automatic Caching:
  If you don't want automatic caching, set package-manager-cache: false in your workflow. This disables the new behavior and restores the previous setup. Please refer to the documentation– Caching Packages for more information.

• The hosted runners have preinstalled versions of software such as yarn node and etc. The main purpose of setup-node is to set up Nodejs on the machine that is why we're not going to install some extra tools. Besides, that if the action had been installing tools by default it would require clean up machine from it. It looks like something out of scope of action.

• pnpm Error:
  As with previous versions of the action, when using pnpm caching with actions/setup-node, it’s important to ensure that pnpm is preinstalled before the action runs. The action itself does not manage this installation.

  Error: Unable to locate executable file: pnpm. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also check the file mode to verify the file is executable.
  

  This error comes from scripts expecting pnpm to be installed. The action itself does not manage this installation. For greater clarity, we’ve improved log messaging in PR #1336.

• Yarn Version Error:
  The yarn error regarding version mismatch (e.g., "packageManager": "[email protected]", but Yarn 1.22.22 is installed) is a Yarn-specific issue (tracked here). This issue is triggered when the action attempts to create the yarn cache directory for caching. With v5, this error can appear because auto-caching is enabled by default. To mitigate this issue and restore the old behavior, set package-manager-cache: false to disable automatic caching.

Thank you again for your feedback!

[jakebailey]

This error comes from scripts expecting pnpm to be installed. The action itself does not manage this installation.

This is not my understanding. This action attempts to run pnpm when it is not installed to do, because packageManager says to use it, which will always fail becuase it's not installed, which means you must always set package-manager-cache: false if pnpm is in packageManager.

The same goes for yarn, becuase the version of yarn that's preinstalled on GHA machines is old. I don't see a world in which the old, unmaintained yarn v1 is updated to change this?

The upshot is that becuase pnpm and yarn were the only "officially" supported corepack package managers, no value of packageManager works. The only one that might work is npm, which is technically usable in corepack, but all that the action will do is run the wrong version of npm and cache it instead.

For greater clarity, we’ve improved log messaging in https://github.com/actions/setup-node/pull/1336.

This link appears to be unrelated. What PR contains the logging?

[Julusian]

The yarn error regarding version mismatch (e.g., "packageManager": "[email protected]", but Yarn 1.22.22 is installed) is a Yarn-specific issue (https://github.com/yarnpkg/yarn/issues/9015).

I dont agree with this conclusion.

yarn v1 is eol and has been since 2020. Since then it appears to have gotten a bunch of small patch fixes but nothing major. As such, it does not support the packageManager field; the extent of its support is to detect it is there and to fail with an error as it has encountered a condition that it does not support. It clearly says right in that error that corepack should be used, as that is almost always the way to load the correct version of yarn.

For yarn v2 and v3, the v1 binary was capable of chain loading the correct executable, but that is no longer the recommended approach with yarn v4. This is not a bug, but an intentional choice.

If it didnt produce this error, then (in any project setup with that new flow intended to be used with corepack it would ignore that the packageManager field was set (and as the yarn1 binary doesn't support or detect yarn v4 in any other way), it would continue executing as yarn v1, which would perform the wrong steps to enable caching. Which is also not the correct behaviour, and would result in the caching doing nothing.

So I don't agree that https://github.com/yarnpkg/yarn/issues/9015 is the bug that is the problem. The problem is that in order to correctly run yarn v4 corepack is needed (if following the setup guide fully).

The conclusion I draw from this is that either setup-node should support enabling corepack (ideally doing it automatically if yarn4 is used), or it should not fail when trying to enable caching for yarn4. As it stands, almost yarn4 user (except those who are still using the old approach) will encounter this failure and have to set the property to opt out of caching.
I expect it is too late to consider supporting corepack, as node has decided to stop shipping it, so perhaps it is out of scope for this action. But in that case, this action shouldnt assume that it can setup caching for yarn4.

Alternatively, perhaps the problem is that yarn1 is still clinging to life by various places refusing to drop it. I am frequently finding new projects using it because they dont realise it is eol, and yet the maintainers of yarn dont want to kill it off entirely because the upgrade path to modern yarn requires some effort in workflow changes. The github actions images including it is a part of this refusal to let it die, if it wasnt there anymore then this discussion would be different.

You could argue that the yarn1 binary should have been updated to handle this new flow too, but corepack was supposed to be the answer to this. The yarn1 binary would have to duplicate a majority of the code in corepack to be able to handle this.
I havent used the yarn1 binary directly in years; I always enable corepack instead and it will choose the correct version (including the correct version of yarn1) instead.

[alexaka1]

If you don't want automatic caching, set package-manager-cache: false in your workflow. This disables the new behavior and restores the previous setup. Please refer to the documentation– Caching Packages for more information.

I would still push back on the fail closed behaviour of caching, that does not make sense to me.

Also the mentioned docs are not very reassuring when they show Node 14, Pnpm 6.x and Yarn 1/2 as examples. All 4 of them end of life for 4+ years now.

[priyagupta108]

Hello everyone,

Thank you for your valuable feedback and insights.

After careful review, we've identified compatibility issues with automatic caching for pnpm and yarn in v5. To enhance stability and minimize disruption, automatic caching will now be enabled only for npm by default, as introduced in PR #1374. For other package managers, such as pnpm and yarn, automatic caching will be disabled by default. If you would like to use caching with these package managers, you can still do so by explicitly setting the cache input.

We believe this change will help prevent the immediate failures some of you have experienced with pnpm and yarn, and provide a smoother experience moving forward.

Thank you again for your continued support and collaboration!

[tagliala]

Hello, does it mean that we should expect a v6 version of the action with package-manager-cache: false by default?

[priyagupta108]

Hello everyone,

As part of PR #1374, we introduce detection support for devEngines.packageManager, enabling automatic caching for npm dependencies. This update will be included in the upcoming patch release of v5. We hope this enhancement helps streamline workflows and improve consistency across your projects.

Your feedback and suggestions are appreciated. Please take a look and share your thoughts.

[dominikg]

Do i understand #1374 correctly that it disables automatic caching for pnpm again?

This would be breaking for users who did update to v5 and removed the explicit cache input.

[Julusian]

This would be breaking for users who did update to v5 and removed the explicit cache input.

Not just pnpm, any users of yarn 1, and some (most?) users of yarn2/3

I agree that changing this behaviour now is a breaking change.
The solution I would like to see is that if no package-manager-cache option has been specified it should try to enable caching, and fail gracefully if it is unable to