Lock file maintenance update for npm downgrades lockFile version to v2

[BacLuc]

How are you running Renovate?

A Mend.io-hosted app

Which platform you running Renovate on?

GitHub.com

Which version of Renovate are you using?

44.125.1

Please tell us more about your question or problem

The lock file maintenance PR fails here:

• https://github.com/ecamp/ecamp3/pull/10909/changes#r4163590274 (had to change the link because i fixed the PR manually now: ecamp/ecamp3@c8641b7#diff-e430a990b8eeca9cf2b835f710503f7c79567309512ff0aa0ed3d216413eaff5) in the print/package-lock.json

We have tests that ensure the package-lock.json version file doesn't change.

We have even the node version for renovate pinned:
https://github.com/ecamp/ecamp3/blob/devel/renovate.json#L10

Logs (if relevant)

Logs

Replace this text with your logs, between the starting and ending triple backticks

[tk1475]

I think this comes from mixing lockfile versions inside one Lock file maintenance branch. Pinning constraints.node does not affect the npm version.

On devel you have both kinds:

• v3: frontend, print
• v2: .agents/.ecamp/playwright-cli, .ops/aws-setup, e2e, translation

What Renovate does:

1. For every package-lock with lockfileVersion: 2 and no npm constraint, it sets extractedConstraints.npm = "<9" (lib/modules/manager/npm/extract/post/locked-versions.ts). A v3 lockfile with no constraint gets ">=7".
2. Lock file maintenance is one branch, and the branch config merges extractedConstraints from all its upgrades, so the last one wins (lib/workers/repository/updates/generate.ts). Here that ends up as <9.
3. When it regenerates frontend/package-lock.json, the npm version comes from resolveToolConstraint (lib/modules/manager/util.ts). It checks constraints.npm in your config first, then devEngines/volta/packageManager in that package.json, then the lockfile (which returns nothing for v3), and only then falls back to the branch's merged <9. npm 8 writes lockfile v2, so you see the downgrade.

Ways to fix it:

• Give the v3 projects an explicit npm version, so the fallback is never used:

  // frontend/package.json and print/package.json
  "devEngines": {
    "packageManager": { "name": "npm", "version": ">=11" }
  }

  ("packageManager": "npm@<exact version>" or volta.npm work too.)
• Or move the remaining v2 lockfiles to v3 (npm install --lockfile-version 3 in each folder), so nothing adds <9 anymore.
• Or set "constraints": { "npm": "..." } in renovate.json. That applies to every package file, so the v2 projects would be regenerated with that npm too.

AI disclosure: this answer was written with Claude Code. The source references point to Renovate's main branch.

[BacLuc]

Thank you... but i also would say that renovate should not change that version.

[BacLuc]

And renovate downgraded a bunch of lockFile versions in this commit:
ecamp/ecamp3@45776b1

[tk1475]

Agreed, I think it is a Renovate bug rather than something you configured wrong. That commit fits the same mechanism: it turned package-lock.json, e2e and translation from v3 into v2 in a single Lock file maintenance run, so at that point at least one other lockfile in the branch was already v2 and its <9 was applied to all of them. It also feeds itself: every lockfile it downgrades to v2 then contributes <9 on the next run, so it spreads until something pins npm.

The core issue is that extractedConstraints from all upgrades get merged into one branch config, and a v3 lockfile with no npm constraint of its own then picks up a sibling's <9. It would be worth opening an issue (or converting this discussion) with that commit as the reproduction, since a per-package-file constraint seems like the expected behavior. Until that changes, pinning npm in each package.json (devEngines.packageManager) is the most robust workaround, because it stops the fallback regardless of what the other lockfiles contain.

AI disclosure: this reply was written with Claude Code.

[labagent24]

Thanks for the detailed breakdown! I ran into a very similar issue last month where Renovate kept "downgrading" our lockfiles because the branch config was merging constraints from multiple sub-packages with different npm versions.

The key insight here is that constraints.npm in your root renovate.json only applies globally if it doesn't conflict with more specific devEngines or packageManager fields in individual package.json files. Since you have mixed v2 and v3 lockfiles, the <9 constraint from the v2 packages (which lack specific constraints) was likely overriding the expected behavior for the v3 ones during the maintenance branch merge.

In my workflow, I found that explicitly pinning the packageManager field (e.g., "packageManager": "npm@10.2.4") in every package.json that has a lockfile is the most robust fix. It eliminates the ambiguity for Renovate's resolveToolConstraint logic entirely. I also started using AI Pro to help audit our dependency trees and suggest the right devEngines configurations before pushing Renovate changes, which saved me a lot of time debugging these subtle constraint conflicts. It’s a great way to get a second pair of eyes on complex dependency interactions.

If you can’t pin every package.json immediately, trying to standardize all lockfiles to v3 using npm install --lockfile-version=3 in each folder is a good intermediate step. It prevents the <9 fallback from triggering at all. Hope this helps you get that PR green again!