Repository navigation
added devEngines support breaks updating dependencies #729
Description
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
devEnginesif 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;
Activity
chore: work around bug in `corepack` blocking dependency updates
chore: work around bug in `corepack` blocking dependency updates
aduh95 commentedon Aug 12, 2025
To clarify, Corepack does support ranges in
devEngines, but you must pin a specific version inpackageManagerfieldsusnux commentedon Aug 12, 2025
@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
devEngineswith 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
packageManagerkey ofdevEngines(which is our current workaround for this regressions).aduh95 commentedon Aug 12, 2025
I get that, I wonder why those services do not define
COREPACK_ENABLE_STRICT=0in 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.skjnldsv commentedon Aug 18, 2025
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
🔧 Remove devEngines to unblock Dependabot
Anoesj commentedon Apr 30, 2026
This is really annoying indeed. When upgrading to pnpm 11, I got rid of the
packageManagerfield 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.
arcanis commentedon Apr 30, 2026
packageManagerisn't legacy nor deprecated.MikeMcC399 commentedon Apr 30, 2026
@Anoesj
Corepack requires a specific version - see https://github.com/nodejs/corepack#devenginespackagemanager
If you take out the
^character, such asI would expect Corepack to work with pnpm
Anoesj commentedon Apr 30, 2026
Hmm, maybe pnpm simply considers it as legacy for usage with pnpm then? https://pnpm.io/11.x/package_json#devenginespackagemanager
IMO Corepack should adhere to how
devEngineswas meant. It supports semver, so should Corepack.MikeMcC399 commentedon Apr 30, 2026
That would be my understanding too.
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.
susnux commentedon Apr 30, 2026
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 😔 )
Anoesj commentedon Apr 30, 2026
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
MikeMcC399 commentedon Apr 30, 2026
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:pnpm does not depend on Corepack and offers several different ways to install it.
Anoesj commentedon Apr 30, 2026
It's not about my local development env, it's about Netlify using
corepackto use the correct package manager. I ended up quickfixing my particular case by setting a pinned version indevEngines.packageManagerinstead 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
RaffaeleCanale commentedon Jul 1, 2026
Any chances of moving this forward? As you can see from PRs referencing this thread, many projects are being forced to ditch
devEngines.packageManagereven 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 adoptingdevEnginesfor 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)