feat: Support volta, asdf, and package.json engines for declaring version

[happycollision]

⚠️ I only ran the build script. Not sure if there is anything else needed.

This addresses #109 and #84 and could be extended later to also address #150.

Using the same logic as actions/setup-node, we can support asdf, volta or other version management techniques.

I thought it'd be nice to allow something like this:

on:
  - push
  - pull_request

jobs:
  install:
    runs-on: ubuntu-latest

    steps:
      - uses: pnpm/action-setup@v4
        with:
          version_file_path: ".tool-versions" # with asdf
          # version_file_path: "package.json" # with volta or package.json's `engines`

[zkochan]

Looks weird to destructure it twice. Just use let for all.

[happycollision]

Heh, I agree. I just wanted to change as little as possible from the code I snagged to it was more comparable. I’ll change it though, since that is a less important goal.

[KSXGitHub]

This is problematic. .tool-versions and package.json are completely different formats and should be treated as different features.

[happycollision]

Honestly, the only reason I did it this way was to match up with how they do it for node versioning in the referenced lib. I figure if js devs are familiar with any GitHub actions at all, it’s likely that one.

I’ll rethink the inputs throwing out that goal and come back with something else.

Or not. Heh. If I have the time I will.

[KSXGitHub]

@zkochan Normally, I only want @pnpm/action-setup to focus only on pnpm. This action supporting corepack makes sense because pnpm itself supports corepack. Do you want to add support for additional tooling that pnpm doesn't commit to support?

@happycollision Shouldn't volta and asdf have their own GH actions?

[happycollision]

@happycollision Shouldn't volta and asdf have their own GH actions?

I doubt it? I assume the best actions to use for setup are the incredibly common one provided by the GH Actions team for node and then for pnpm, the one maintained by the actual developers of pnpm. 😇

I use a node action to setup node and this pnpm action to set up pnpm in CI (just as described in your docs). But to version control in development I use asdf, sometimes Volta. All I really want is a single, canonical place to declare a version and have it respected by all those tools, rather than assume everyone on my team is familiar enough with all of them to know and remember to update the version in multiple places. So that’s my particular use case.

Now, the .tool-versions format is easy enough to dig through with shell scripting, but if you give people an easy way to do it, you’d save people some time and effort. This, I assume, is why the node action offers to read these common version declaration files.

I gave my other answers above before reading this comment, so until I hear back from you guys, I’ll sit on this so you can decide what is best for the project. Feel free to close this out if you like.

Cheers.

Side note: We are in the middle of transitioning from npm to pnpm at my workplace. I am the one doing the work for it, and I am loving the benefits I am seeing. Thanks for the incredible work on this package manager.

[KSXGitHub]

@happycollision Both volta and asdf aim to be the single, canonical place to configure all the versions of JS runtimes and package managers if I'm not mistaken? Them not having GH actions of their own is a flaw they should address.

pnpm initially also didn't have a GH action, so I made one, and proposed with zkochan to move it from my account to the @pnpm org, making it official.

[happycollision]

@KSXGitHub

I can see where volta might do such a thing. (Perhaps they have already.) But asdf is an "everything" version manager with plugins for each thing it manages, so I doubt there would be an official such thing from them. The people who maintain the nodejs plugin are not the same people who maintain the pnpm plugin.

Not that my doubting it makes it less "their problem".

What would you say to just adding some docs that show the very workaround I am using for asdf? I could probably figure something for Volta as well, since it is just reading package.json

    - name: Determine pnpm version
      id: pnpm_version
      run: echo "PNPM_VERSION=$(cat .tool-versions | grep pnpm | awk '{print $2}')" >> $GITHUB_ENV
      shell: bash

    - name: Install pnpm
      uses: pnpm/action-setup@v4
      with:
        version: ${{ env.PNPM_VERSION }}

update

Yeah, volta has their own: https://github.com/volta-cli/action

So I would bet that when pnpm support is no longer experimental, it's something they'd do. Still makes sense to me to document this fairly simple workaround for the asdf people.

[KSXGitHub]

Creating a GH action for asdf should be simple. You can create it yourself then propose to the asdf people to move it to their org. After all, it's just downloading asdf and executing everything through it.

Corepack has corepack pnpm <command>, I guess asdf acts the same? If you're using asdf, I would recommend replacing every pnpm in your script with asdf pnpm.