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
Description:
Ideally, I'd like the default configuration of this action to "just work" regardless of the package manager, lockfile, and other decisions made by a repository, so I can reuse it in composed actions and workflows. Currently, there isn't a straightforward way to enable caching without hard coding a specific package manager, and using pnpm requires adding different steps before this action, making its usage inconsistent with npm and yarn users.
I am aware of these related issues, but I wanted to make an issue dedicated to discussing how to achieve this goal at a higher level:
Justification:
As a real world example, I have a GitHub template repository that sets up some Node.js tools with a package.json file. To keep it beginner friendly and flexible, I'm intentionally not including lockfiles for any specific package manager. I considered setting up GitHub Actions so generated repositories would have a good CI setup, however there's not a single configuration I could enable for this action that would work with npm, yarn, and pnpm users.
Other CI services solve this problem by following convention over configuration. For example, Travis CI runs yarn instead of npm install when there is a yarn.lock.
Are you willing to submit a PR?
So far, I'd suggest that we depend on preferred-pm for more implicit package manager selection logic and use it to install yarn or pnpm dynamically (optionally with corepack). If there's consensus on this or another solution, I may try to submit a PR, though it may depend on PRs for the related issues.
The text was updated successfully, but these errors were encountered:
Hello @nickmccurdy can you please clarify how this issue differ from this one #306 ? Namely what does the term "simpler configuration" includes? Or, in other words, what inputs besides cache: 'auto' you would like to inherit from the environment?
@nickmccurdy i am closing the issue due to inactivity for a long time, but please feel free to reopen it or create another one if the problem still exists
Description:
Ideally, I'd like the default configuration of this action to "just work" regardless of the package manager, lockfile, and other decisions made by a repository, so I can reuse it in composed actions and workflows. Currently, there isn't a straightforward way to enable caching without hard coding a specific package manager, and using pnpm requires adding different steps before this action, making its usage inconsistent with npm and yarn users.
I am aware of these related issues, but I wanted to make an issue dedicated to discussing how to achieve this goal at a higher level:
Justification:
As a real world example, I have a GitHub template repository that sets up some Node.js tools with a
package.json
file. To keep it beginner friendly and flexible, I'm intentionally not including lockfiles for any specific package manager. I considered setting up GitHub Actions so generated repositories would have a good CI setup, however there's not a single configuration I could enable for this action that would work with npm, yarn, and pnpm users.Other CI services solve this problem by following convention over configuration. For example, Travis CI runs
yarn
instead ofnpm install
when there is ayarn.lock
.Are you willing to submit a PR?
So far, I'd suggest that we depend on
preferred-pm
for more implicit package manager selection logic and use it to install yarn or pnpm dynamically (optionally with corepack). If there's consensus on this or another solution, I may try to submit a PR, though it may depend on PRs for the related issues.The text was updated successfully, but these errors were encountered: