Skip to content

feature request: cache: 'auto' #306

Description

@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

Activity

  1. maxim-lobanov commented on Aug 6, 2021

    @maxim-lobanov
    Contributor

    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.

  2. privatenumber commented on Aug 6, 2021

    @privatenumber
    Author

    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

  3. privatenumber commented on Oct 8, 2021

    @privatenumber
    Author

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

  4. utamori commented on Oct 16, 2021

    @utamori

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

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

  5. nickserv commented on Sep 24, 2022

    @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.

  6. dmitry-shibanov commented on Jan 24, 2023

    @dmitry-shibanov
    Contributor

    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.

  7. nickserv commented on Jan 24, 2023

    @nickserv

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

  8. privatenumber commented on Jan 25, 2023

    @privatenumber
    Author

    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.

  9. nickserv commented on Jan 25, 2023

    @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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    feature requestNew feature or request to improve the current logic

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions