Support for semver ranges?

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.

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.

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?

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

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

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

@boneskull

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

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

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.

@boneskull

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

@aduh95

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

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.

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.

@mrgrain

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

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

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.

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.

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.

fix: explicitly set our preferred package manager for js dependencies (…

+1

migrate to mise, update dependencies

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.

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?

fix: remove package.json packageManager field (#1529)

+1

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

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.

At least, running corepack pnpm@10.0.0 foo bar should ignore packageManager field, while currently it will throw an error if packageManager is specified in semver ranges.

Not having semver makes this field so damn annoying when working as a team.

@arcanis

As of 12 Aug 2026 (pnpm@11.21.0), a fresh pnpm init project breaks immediately with Corepack because of this lack of support of version ranges:

$ ls -al $(which pnpm)
lrwxr-xr-x@ 1 k  admin  64 Jan 14  2026 /opt/homebrew/bin/pnpm -> ../Cellar/node@24/24.13.0/lib/node_modules/corepack/dist/pnpm.js

$ mkdir a

$ cd a

$ pnpm init
Wrote to /Users/k/p/a/package.json

{
  "name": "a",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devEngines": {
    "packageManager": {
      "name": "pnpm",
      "version": "^11.21.0",
      "onFail": "download"
    }
  },
  "type": "module"
}

$ pnpm -v
Invalid package manager specification in package.json (pnpm@^11.21.0); expected a semver version

Reported over here:

"Invalid package manager specification in package.json (pnpm@^11.1.3); expected a semver version" with corepack pnpm/pnpm#11732

@arcanis or other maintainers: what are your thoughts here? Would Corepack support version ranges, at least for pnpm?

Or is it no longer recommended to use Corepack with pnpm?

pnpm has now unfortunately dropped all mentions of Corepack from the docs because of this 🙁

"Invalid package manager specification in package.json (pnpm@^11.1.3); expected a semver version" with corepack pnpm/pnpm#11732 (comment)

Workaround: Remove `devEngines` block from `pnpm init`

For people stuck with Corepack and pnpm (eg. before you have migrated off Corepack), there's a workaround:

$ pnpm init --init-package-manager false
Wrote to /Users/k/p/b/package.json

{
  "name": "b",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "type": "module"
}

Compare that with the full pnpm init:

$ pnpm init
Wrote to /Users/k/p/b/package.json

{
  "name": "b",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devEngines": {
    "packageManager": {
      "name": "pnpm",
      "version": "^11.21.0",
      "onFail": "download"
    }
  },
  "type": "module"
}

Navigation Menu

Repository navigation

Support for semver ranges? #95

1 remaining item

Workaround: Remove `devEngines` block from `pnpm init`

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support for semver ranges? #95

Description

Activity

shellscape commented on May 2, 2022

styfle commented on Jun 10, 2022

jsumners commented on Jun 10, 2022

aduh95 commented on Jun 29, 2022

boneskull commented on Aug 6, 2023

aduh95 commented on Aug 6, 2023

boneskull commented on Aug 6, 2023

boneskull commented on Aug 9, 2023

aduh95 commented on Aug 9, 2023

boneskull commented on Aug 9, 2023

uiolee commented on Oct 25, 2023

mrgrain commented on Nov 1, 2023

boneskull commented on Nov 13, 2023

mrgrain commented on Nov 13, 2023

MattSilvaa commented on Dec 19, 2023

1 remaining item

arcanis commented on Jan 12, 2024

mcollina commented on Jan 12, 2024

mrgrain commented on Jan 12, 2024

xsjcTony commented on Apr 25, 2024

jordanebelanger commented on May 7, 2024

Aeolun commented on May 14, 2024

guilherssousa commented on Aug 14, 2024

anthonyalayo commented on Jan 23, 2025

aduh95 commented on Jan 24, 2025

zanminkian commented on Aug 26, 2025

jordanebelanger commented on Jan 21, 2026

karlhorky commented on Aug 12, 2026

Workaround: Remove devEngines block from pnpm init

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Workaround: Remove `devEngines` block from `pnpm init`