Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support different package managers / versions #6

Open
dominykas opened this issue Oct 11, 2021 · 2 comments
Open

Support different package managers / versions #6

dominykas opened this issue Oct 11, 2021 · 2 comments
Labels
enhancement New feature or request

Comments

@dominykas
Copy link
Member

It should be possible to specify a package manager, package manager version or even a matrix of package managers.

@dominykas dominykas added the enhancement New feature or request label Jan 2, 2022
dominykas added a commit that referenced this issue Jan 4, 2022
npm supports this as of v7+ and it is a better option than `npm install` until #6 is implemented
@dominykas
Copy link
Member Author

dominykas commented Feb 15, 2022

Some thoughts on how this could be implemented...

  • Not strictly necessary for the MVP, but going forward, we'd probably want to add a mapping of Node.js versions to supported package manager ranges (e.g. Node 6 can run npm@>=3 <7)
    • This is because we can't simply install latest or it would break things on older Nodes
  • I'd like to change the default version of npm to be "latest-supported" (which would be latest for modern nodes, and an older version once the old version mapping is added) - i.e. unless specified otherwise, this would npm i -g npm@[latest supported] (or the corepack equivalent for Node.js 15+?)
    • Is this a breaking change? Good thing we didn't tag v1 yet 😎
    • Should the decision of whether to call corepack or npm be configurable? How does that affect caching?
  • We'd need a sane way to express the package manager matrix. Things that should be easy to do:
    • "run with latest supported npm, yarn and pnpm in all Node.js versions in the matrix"
      • I'd like to treat [manager]@latest as "latest supported", as opposed to "version published at latest dist-tag"
      • As shared workflows can only take strings as params, we'd probably need to do the same thing that we do for runs-on, i.e. support a YAML array inside a string as well as a comma separated string, so the following are equivalent:
        • package-manager: npm, yarn, pnpm
        • package-manager: "[ 'npm', 'yarn', 'pnpm' ]"
    • "run with default installed version of npm in all Node.js versions in the matrix"
      • I'd introduce the npm@default version which would simply not install anything
      • I'm not sure if or how this would be applicable to corepack based management?
    • "run with manager1@v1, manager1@v2, npm@latest, npm@default, manager2@v9 in all Node.js versions in the matrix"
      • This bit should be smart enough to add unsupported manager versions into excludes
  • If there's a single package manager used (i.e. either default npm is kept, or package-manager: yarn is configured), then the matrix should use null for the package-manager (and fall back to correct value for the actual installation), so that the status check names are not cluttered.

@ljharb
Copy link
Member

ljharb commented Feb 15, 2022

You can look at https://github.com/nvm-sh/nvm/blob/39d9a42c359df5dbf37c5000af8192f14a280b94/nvm.sh#L170-L330 for a mapping of actual npm/node versions that work; afaik that knowledge doesn't exist anywhere else.

I don't think we should be using corepack at all; it's experimental and has received some pushback around the way it works.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants