feature request: cache: 'auto'

[privatenumber]

I would like to request that "automatic detection" mode be supported for the cache option.

The option would check whether the following files exists to determine which caching option (or package manager) to use:
package-lock.json => npm
yarn.lock => yarn
pnpm-lock.yaml => pnpm

[maxim-lobanov]

Hello @privatenumber , we have discussed it in past but looks like we can't determine package manager unequivocally.
For example, yarn.lock can be generated and used for both Yarn and NPM 7.

[privatenumber]

IMO that's an extra option we get to choose from rather than a blocking problem:

package-lock.json => npm
pnpm-lock.yaml => pnpm
yarn.lock => yarn or npm, but yarn is likely the safer option

Hello!
I have a project that uses yarn AND npm, I know that I can define several files in cache-dependency-path (dir1/package-lock.json dir2/yarn.lock), but I am not sure if I can define several package managers in the "cache" option.
My current config is:

 - name: Setup Node
    uses: actions/setup-node@v2
    with:
      node-version: '14.17'
      cache: 'npm'
      cache-dependency-path: |
        client/package-lock.json
        server/yarn.lock

it's this safe? or can I define this better?

[privatenumber]

Consider using Stack Overflow, or at least a separate Issue, for help.

[utamori]

If the target is a project that uses corepack, it can be uniquely identified.

https://nodejs.org/api/corepack.html

[nickserv]

I suggest using the preferred-pm package (with corepack preferably). It's already used by pnpm and Astro, so adopting it would make the action's behavior more consistent with other JavaScript tools. It also inspects what files exist in node_modules, which in some cases can clear up ambiguity when different lockfiles are used. That being said, I don't think it's good practice to have multiple lockfiles committed to one repository anyway.

[dmitry-shibanov]

Hello everyone. For now I'm going to close the issue because as it was described some dependency files can be used for both package managers. Besides, for some customers it can be inconvenient about which package manager is used.

[nickserv]

But the preferred-pm package would solve this problem, as I explained. And what's inconvenient?

[privatenumber]

The reason for closing is very vague and weak.

I agree preferred-pm solves this issue. The logic is straightforward: https://github.com/zkochan/packages/blob/master/preferred-pm/index.js

The packageManager property in package.json (from Corepack) also indicates which package manager should be used.

There are plenty of signals already used by the community.
Please re-open.

[nickserv]

If we can't have this in this action officially, I'm going to fork it. However if the maintainers are willing to reopen this, it would be nice to not cause further fragmentation.