Support different package managers / versions

[dominykas]

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

[dominykas]

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]

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.