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`

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

[zkochan]

I think it is OK to read the setting from those files. Those are just tools used during local development.

[happycollision]

Considering @ksgithub's concerns versus @zkochan's general approval, I added two commits to fixup into the main one, which throw errors and log a touch more info so that if something is going wrong, the user has a shot at seeing what it is.

So yes, we are still treating package.json and .tool-versions as the same feature, but hopefully the additional strictness of failing when a version file is supplied but we cannot find a version, and also logging the version that was found, will suffice.

[KSXGitHub]

The behavior would be more predictable if you match the extension of versionFilePath against .json and .tool-versions instead of try. We can even be stricter: match the basename of versionFilePath against package.json and .tool-versions.

[KSXGitHub]

Suggested change

	if (manifest.volta?.pnpm) {
	return manifest.volta.pnpm as string
	}
	if (manifest.engines?.pnpm) {
	return manifest.engines.pnpm as string
	}
	if (typeof manifest.volta?.pnpm === 'string') {
	return manifest.volta.pnpm
	}
	if (typeof manifest.engines?.pnpm === 'string') {
	return manifest.engines.pnpm
	}

[KSXGitHub]

Also, what if both manifest.engines.volta.pnpm and manifest.engines.pnpm are specified but different from each other? Shouldn't it throw an error?

[KSXGitHub]

Regex is overkill here.

The format is simple enough. Just use .split('\n'), .find(), .startsWith('pnpm'), and .slice('pnpm'.length).trim().

[happycollision]

The main reason I opened this PR was just to get a quick win by using almost the exact same implementation that the nodejs action uses for node version management.

It seems to me that the kind of solution they use is not to your liking, which is understandable.

I don’t really have the time to continue this back and forth at this time, so I’ll close the PR and open a new one if I feel I have the time and desire again to tackle this in a way you prefer in the future.

[ksgithub]

Guys, Although would love to review your PRs, you've got the wrong guy in your email chain. Please remove me from this chain. Thanks

…

On Tue, Jan 21, 2025 at 8:29 AM Don Denton ***@***.***> wrote: The main reason I opened this PR was just to get a quick win by using almost the exact same implementation that the nodejs action uses for node version management. It seems to me that the kind of solution they use is not to your liking, which is understandable. I don’t really have the time to continue this back and forth at this time, so I’ll close the PR and open a new one if I feel I have the time and desire again to tackle this in a way you prefer in the future. — Reply to this email directly, view it on GitHub <#151 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APJCKIWUFQCPP5HEDB3GVED2LZDSDAVCNFSM6AAAAABSUIT6PCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBUG4ZTSNRSHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Khaled Saad