added devEngines support breaks updating dependencies

The recent devEngines support seems to cause errors with dependabot (all updates broken), this is an example but there are more packages like this:

Error running package manager command: corepack npm install vite@7.0.5 --force --dry-run false --ignore-scripts --package-lock-only
Error: Invalid package manager specification in package.json (npm@^10); expected a semver version
NPM : Invalid package manager specification in package.json (npm@^10); expected a semver version

Context:
Within our project we have this in the package.json:

"engines": {
    "node": "^20.11.0 || ^22 || ^24"
  },
  "devEngines": {
    "packageManager": {
      "name": "npm",
      "version": "^10",
      "onFail": "error"
    },
    "runtime": {
      "name": "node",
      "version": "^22",
      "onFail": "error"
    }
  }

(We support a wide range of engines - but for development devs should only use Node 22 and NPM 10 to have consistent compiled assets (and test results)).

I guess this is caused here: https://github.com/nodejs/corepack/pull/643/files#r2234021913

I see two ways to fix corepack:

Only enforce strict version if a full version was passed, see patch:

Details

diff --git a/sources/specUtils.ts b/sources/specUtils.ts
index edd5c7e..82c1435 100644
--- a/sources/specUtils.ts
+++ b/sources/specUtils.ts
@@ -77,47 +77,51 @@ function warnOrThrow(errorMessage: string, onFail?: DevEngineDependency[`onFail`
       console.warn(`! Corepack validation warning: ${errorMessage}`);
   }
 }
-function parsePackageJSON(packageJSONContent: CorepackPackageJSON) {
-  const {packageManager: pm} = packageJSONContent;
-  if (packageJSONContent.devEngines?.packageManager != null) {
-    const {packageManager} = packageJSONContent.devEngines;
-
-    if (typeof packageManager !== `object`) {
-      console.warn(`! Corepack only supports objects as valid value for devEngines.packageManager. The current value (${JSON.stringify(packageManager)}) will be ignored.`);
-      return pm;
+function parsePackageJSON({devEngines, packageManager}: CorepackPackageJSON) {
+  const spec = {
+    packageManager,
+    enforceExactVersion: true,
+  };
+
+  if (devEngines?.packageManager != null) {
+    const {packageManager: pm} = devEngines;
+
+    if (typeof pm !== `object`) {
+      console.warn(`! Corepack only supports objects as valid value for devEngines.packageManager. The current value (${JSON.stringify(pm)}) will be ignored.`);
+      return spec;
     }
-    if (Array.isArray(packageManager)) {
+    if (Array.isArray(pm)) {
       console.warn(`! Corepack does not currently support array values for devEngines.packageManager`);
-      return pm;
+      return spec;
     }
 
-    const {name, version, onFail} = packageManager;
+    const {name, version, onFail} = pm;
     if (typeof name !== `string` || name.includes(`@`)) {
       warnOrThrow(`The value of devEngines.packageManager.name ${JSON.stringify(name)} is not a supported string value`, onFail);
-      return pm;
+      return spec;
     }
     if (version != null && (typeof version !== `string` || !semverValidRange(version))) {
       warnOrThrow(`The value of devEngines.packageManager.version ${JSON.stringify(version)} is not a valid semver range`, onFail);
-      return pm;
+      return spec;
     }
 
     debugUtils.log(`devEngines.packageManager defines that ${name}@${version} is the local package manager`);
 
-    if (pm) {
-      if (!pm.startsWith?.(`${name}@`))
-        warnOrThrow(`"packageManager" field is set to ${JSON.stringify(pm)} which does not match the "devEngines.packageManager" field set to ${JSON.stringify(name)}`, onFail);
-
-      else if (version != null && !semverSatisfies(pm.slice(packageManager.name.length + 1), version))
-        warnOrThrow(`"packageManager" field is set to ${JSON.stringify(pm)} which does not match the value defined in "devEngines.packageManager" for ${JSON.stringify(name)} of ${JSON.stringify(version)}`, onFail);
-
-      return pm;
+    if (packageManager) {
+      if (!packageManager.startsWith?.(`${name}@`))
+        warnOrThrow(`"packageManager" field is set to ${JSON.stringify(packageManager)} which does not match the "devEngines.packageManager" field set to ${JSON.stringify(name)}`, onFail);
+      else if (version != null && !semverSatisfies(packageManager.slice(pm.name.length + 1), version))
+        warnOrThrow(`"packageManager" field is set to ${JSON.stringify(packageManager)} which does not match the value defined in "devEngines.packageManager" for ${JSON.stringify(name)} of ${JSON.stringify(version)}`, onFail);
+      return spec;
     }
 
-
-    return `${name}@${version ?? `*`}`;
+    return {
+      enforceExactVersion: semverValid(version),
+      packageManager: `${name}@${version ?? `*`}`,
+    };
   }
 
-  return pm;
+  return spec;
 }
 
 export async function setLocalPackageManager(cwd: string, info: PreparedPackageManagerInfo) {
@@ -233,11 +237,11 @@ export async function loadSpec(initialCwd: string): Promise<LoadSpecResult> {
     process.env = selection.localEnv;
   }
 
-  const rawPmSpec = parsePackageJSON(selection.data);
-  if (typeof rawPmSpec === `undefined`)
+  const {enforceExactVersion, packageManager} = parsePackageJSON(selection.data);
+  if (typeof packageManager === `undefined`)
     return {type: `NoSpec`, target: selection.manifestPath};
 
-  debugUtils.log(`${selection.manifestPath} defines ${rawPmSpec} as local package manager`);
+  debugUtils.log(`${selection.manifestPath} defines ${packageManager} as local package manager`);
 
   return {
     type: `Found`,
@@ -249,6 +253,6 @@ export async function loadSpec(initialCwd: string): Promise<LoadSpecResult> {
       onFail: selection.data.devEngines.packageManager.onFail,
     },
     // Lazy-loading it so we do not throw errors on commands that do not need valid spec.
-    getSpec: () => parseSpec(rawPmSpec, path.relative(initialCwd, selection.manifestPath)),
+    getSpec: () => parseSpec(packageManager, path.relative(initialCwd, selection.manifestPath), {enforceExactVersion}),
   };
 }

Ignore devEngines if it is a version range, see patch:

Details

diff --git a/sources/specUtils.ts b/sources/specUtils.ts
index edd5c7e..183a62e 100644
--- a/sources/specUtils.ts
+++ b/sources/specUtils.ts
@@ -113,8 +113,9 @@ function parsePackageJSON(packageJSONContent: CorepackPackageJSON) {
       return pm;
     }
 
-
-    return `${name}@${version ?? `*`}`;
+    if (semverValid(version)) {
+      return `${name}@${version ?? `*`}`;
+    }
   }
 
   return pm;

chore: work around bug in `corepack` blocking dependency updates

To clarify, Corepack does support ranges in devEngines, but you must pin a specific version in packageManager field

@aduh95

@aduh95 yes I know - but I personally do not want to use Corepack.
it is used by services like Dependabot or Renovate which are used by many projects.

So as soon as we use devEngines with a valid value (semantic version range) those services break because Corepack throws an exception.

From my point of view Corepack should handle this more gracefully and just ignore it. Like it is already doing if you provide an array for the packageManager key of devEngines (which is our current workaround for this regressions).

I get that, I wonder why those services do not define COREPACK_ENABLE_STRICT=0 in their env as I agree it doesn't make much sense for them to fail in this case. Regarding whether Corepack by default should not complain, I don't know, not pinning the version in dev is going against best practices, it sorta makes sense to nudge the users towards following best practices.

@aduh95

Hey @aduh95 👋
Any way we can help this move forward in #730 ?

Bonne journée!

chore: use array for packageManager as workaround (#392)

🔧 Remove devEngines to unblock Dependabot

This is really annoying indeed. When upgrading to pnpm 11, I got rid of the packageManager field at first, since pnpm marks it as "legacy" in their docs. But upon pushing to Netlify, that uses Corepack to select the correct pm and node version. So several tools support semver, since it's valid syntax, but only Corepack doesn't support it, ugh.

PR #730 looks like that would fix the issue. Hopefully a maintainer can find the time to review that PR.

packageManager isn't legacy nor deprecated.

@Anoesj

@Anoesj

Corepack requires a specific version - see https://github.com/nodejs/corepack#devenginespackagemanager

If you take out the ^ character, such as

  "devEngines": {
    "packageManager": {
      "name": "pnpm",
      "version": "11.0.1",
      "onFail": "download"
    }
  },

I would expect Corepack to work with pnpm

packageManager isn't legacy nor deprecated.

Hmm, maybe pnpm simply considers it as legacy for usage with pnpm then? https://pnpm.io/11.x/package_json#devenginespackagemanager

@Anoesj

Corepack requires a specific version - see https://github.com/nodejs/corepack#devenginespackagemanager

If you take out the ^ character, such as

"devEngines": {
"packageManager": {
"name": "pnpm",
"version": "11.0.1",
"onFail": "download"
}
},
I would expect Corepack to work with pnpm

IMO Corepack should adhere to how devEngines was meant. It supports semver, so should Corepack.

Hmm, maybe pnpm simply considers it as legacy for usage with pnpm then?

That would be my understanding too.

IMO Corepack should adhere to how devEngines was meant. It supports semver, so should Corepack.

devEngines was an evolving standard after Corepack was created. I wouldn't expect any major changes to Corepack now. You can read #687 for a discussion about the status and expectations for Corepack to become non-experimental through further development.

devEngines was an evolving standard after Corepack was created. I wouldn't expect any major changes to Corepack now.

That is fine, but then it should simply ignore this property if it cannot adapt.
Because otherwise it will force basically everyone to use the hacky workaround with using array-syntax.
(I doubt dependabot or renovate will implement a global workaround this bug so either corepack fixes it or we have to live with this workaround forever 😔 )

@susnux

devEngines was an evolving standard after Corepack was created. I wouldn't expect any major changes to Corepack now. You can read #687 for a discussion about the status and expectations for Corepack to become non-experimental through further development.

Ah I see, too bad development has stalled a bit. Thanks for your efforts to reboot it though! Should parties like Netlify still count on Corepack or look for (their own) alternatives?

I agree with @susnux, the workarounds suck and quite a bunch of tools and parties rely on Corepack now. Is there anything we can do to help get Corepack up to speed again @MikeMcC399?

Tagging @netlify as this is in their interest as well

Corepack is not enabled by default and if you are using it with pnpm@11, then I suggest to follow the pnpm@11 documentation which advises:

You can pin the version of pnpm used on your project using the following command:

corepack use pnpm@next-11

This will add a "packageManager" field in your local package.json which will instruct Corepack to always use a specific version on that project. This can be useful if you want reproducability, as all developers who are using Corepack will use the same version as you. When a new version of pnpm is released, you can re-run the above command.

pnpm does not depend on Corepack and offers several different ways to install it.

It's not about my local development env, it's about Netlify using corepack to use the correct package manager. I ended up quickfixing my particular case by setting a pinned version in devEngines.packageManager instead of a semver range and that's something I can live with, even though it'd nice to be able to say "this package's dependencies should be managed by with versions " and have corepack respect that, but I understand the difficulties at hand.

fix(dependabot): remove devEngines.packageManager from package.json

Any chances of moving this forward? As you can see from PRs referencing this thread, many projects are being forced to ditch devEngines.packageManager even if it fits their needs and was setup correctly, just because otherwise they cannot use dependabot.

I understand corepack may or may not be interested in investing in devEngines.packageManager, but if supporting the full spec is not acceptable, at least it should allow to opt-out or ignore the field entirely. Right now corepack is positioned as an obstacle for anyone interested in adopting devEngines for what (I presume) is just a minor bug, which is a shame. I see someone attempted a fix (#730), could this be a way forward?

fix: Pin packageManager so Corepack can resolve devEngines

fix: Pin packageManager so Corepack can resolve devEngines (#624)

Navigation Menu

Repository navigation

added `devEngines` support breaks updating dependencies #729

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

added devEngines support breaks updating dependencies #729

Description

Activity

aduh95 commented on Aug 12, 2025

susnux commented on Aug 12, 2025

aduh95 commented on Aug 12, 2025

skjnldsv commented on Aug 18, 2025

Anoesj commented on Apr 30, 2026

arcanis commented on Apr 30, 2026

MikeMcC399 commented on Apr 30, 2026

Anoesj commented on Apr 30, 2026

MikeMcC399 commented on Apr 30, 2026

susnux commented on Apr 30, 2026

Anoesj commented on Apr 30, 2026

MikeMcC399 commented on Apr 30, 2026

Anoesj commented on Apr 30, 2026

RaffaeleCanale commented on Jul 1, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

added `devEngines` support breaks updating dependencies #729