You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
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.
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.
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.
Activity
maxim-lobanov commentedon Aug 6, 2021
Hello @privatenumber , we have discussed it in past but looks like we can't determine package manager unequivocally.
For example,
yarn.lockcan be generated and used for both Yarn and NPM 7.privatenumber commentedon Aug 6, 2021
IMO that's an extra option we get to choose from rather than a blocking problem:
package-lock.json=> npmpnpm-lock.yaml=> pnpmyarn.lock=> yarn or npm, but yarn is likely the safer optionprivatenumber commentedon Oct 8, 2021
Consider using Stack Overflow, or at least a separate Issue, for help.
utamori commentedon Oct 16, 2021
If the target is a project that uses corepack, it can be uniquely identified.
https://nodejs.org/api/corepack.html
nickserv commentedon Sep 24, 2022
I suggest using the
preferred-pmpackage (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 innode_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 commentedon Jan 24, 2023
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 commentedon Jan 24, 2023
But the
preferred-pmpackage would solve this problem, as I explained. And what's inconvenient?privatenumber commentedon Jan 25, 2023
The reason for closing is very vague and weak.
I agree
preferred-pmsolves this issue. The logic is straightforward: https://github.com/zkochan/packages/blob/master/preferred-pm/index.jsThe
packageManagerproperty inpackage.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 commentedon Jan 25, 2023
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.