Support for semver ranges?

[jsumners]

I'd like to write a package.json like:

{
  "packageJson": "pnpm@6"
}

Or maybe pnpm@^6.32.2, etc.

As it stands, adding a package manager to package.json requires a full specified version. This adds more maintenance overhead.

I think this is related to #93.

[shellscape]

Agreed. pnpm v7 was released just yesterday and I'd hoped to use corepack moving forward instead of manually installing it for all of our workflows. This is probably done so along the lines of "pin your dependencies," but doesn't meet all needs.

[styfle]

Would this need to perform a network request every time you do pnpm run <script> to check for the latest pnpm, since you can't rely the cached copy anymore?

[jsumners]

Would this need to perform a network request every time you do pnpm run <script> to check for the latest pnpm, since you can't rely the cached copy anymore?

Good question. I think some sort of "check every X time window" would be acceptable. Similar to https://github.com/ohmyzsh/ohmyzsh/blob/d41ca84af1271e8bfbe26f581cebe3b86521d0db/oh-my-zsh.sh#L59-L62

[aduh95]

It looks like this was originally possible, and was removed in #18.

[boneskull]

This seems kind of odd to restrict matching on exact version when one can provide any dist-tag instead (which can be moved around at will).

Reverting the restriction would help my use case: use corepack to test or try something on a package manager where only the major version matters. I have sinking feeling my use case is out of scope...

[aduh95]

@boneskull The restriction only applies to the package.json ad hoc field, you can still do e.g. corepack [email protected] install, does that cover your use case?

[boneskull]

that wasn't working as of a couple hours ago. corepack npm@7 unknown version or smth to that effect

[boneskull]

wrapping corepack to support this, I've pulled down the result of npm show --json <npm|yarn|pnpm> versions, then use semver to try match a range.

[aduh95]

@boneskull are you using an old version of Corepack maybe? For me, running COREPACK_ENABLE_PROJECT_SPEC=0 corepack npm@7 --version works and returns 7.20.1.

[boneskull]

@aduh95 I wonder if the env var was the problem. Seems to work now, thanks.

[uiolee]

Totally agree.

The exact version of the package manager prevents me from working on different projects. I don't think most projects need an exact package manager. corepack should introduce the semver strategy likes dependencies management do.

[mrgrain]

I always want to use the latest version of my package manager. The exception usually is on a new major release, when I first have to run a few validations.

With the current restrictions to only exact versions, I have to make a change every time I want to update the version of the package manger. Worst case, this needs to be done through a PR and I need to bother a co-worker with a review.

[boneskull]

@mrgrain Couldn't you use a dist tag? e.g., npm@latest

[mrgrain]

@mrgrain Couldn't you use a dist tag? e.g., npm@latest

I don't think dist tags are supported either? If they are, that would certainly be better than nothing.

However the problem with dist tags is

a) it's usually latest which will cause users to receive untested major version upgrades.

b) since a dist tag points to a specific version, we still impose an upgrade to the user.

[MattSilvaa]

Hi! I'm curious whether a decision has been reached to add the functionality back for supporting semver ranges?

[mcollina]

This would be great to implement this before calling it stable.

[arcanis]

I'm still not convinced this is a good idea:

• It prevents using hashes to ensure the version is the expected one
• It gives users a false sense of confidence that their project will always be installable (bugfixes may be breaking changes)

You can already use corepack up whenever you want to upgrade the package manager, I don't think an implicit upgrade should be encouraged as a good practice.

[mcollina]

What i would like the default behavior to be given version of Node.js 22, is that corepack is enabled by default and pnpm i always installs the same major. I might have misunderstood this issue, but it would look like this is needed for that.

[mrgrain]

I'm still not convinced this is a good idea:

• It prevents using hashes to ensure the version is the expected one
• It gives users a false sense of confidence that their project will always be installable (bugfixes may be breaking changes)
  You can already use corepack up whenever you want to upgrade the package manager, I don't think an implicit upgrade should be encouraged as a good practice.

These are vary valid concerns and I understand that we should encourage explicit versions as the best practice. However I believe that many projects do not currently see this as a major concern, otherwise we would see a lot of very specific engines declaration.

The other use case is really around validation. If corepack already has a version of pnpm installed that satisfies the constraint pnpm@6, why should it install a slightly different version? This is just a waste of resources. Like you've said, users can run corepack up to upgrade. Of course explicit versions are still supported if you as owner prefer this. Ultimately this is about choice.

[xsjcTony]

+1

[jordanebelanger]

Every well known package manager supported by the experimental packageManager field uses semver (and most large opensource projects in general). From that perspective where semver is usually expected, it's common sense that it should be possible to restrict to a major version. If the maintainers of a package manager introduce a breaking change for an existing major version by accident and it breaks our installations, so be it, if someone is that worried about that there should simply be a way of specifying an exact version.

[Aeolun]

if someone is that worried about that there should simply be a way of specifying an exact version

Yeah, this is common practice literally everywhere. If you care about getting exact versions, you specify the exact version. If you do not, you specify a range.

I don't really understand how you can make a field that looks like it's a semver specifier, in a file full of semver specifiers, and then not actually make it semver. Like, wut?

[guilherssousa]

+1

[anthonyalayo]

What is the current best practice for this? Remove the entry in the package.json?

[aduh95]

What is the current best practice for this? Remove the entry in the package.json?

You can run corepack up to bump the version in the same major, and corepack use <your package manager>@<major version>.x to use a different major version.