replacementName silently fails for npm peerDependencies (two distinct failure modes)

[straub]

How are you running Renovate?

Mend-hosted app (reproduction), also observed on self-hosted CLI renovate/renovate:43.252.1 in Docker

Which platform are you running Renovate on?

GitHub.com

Which version of Renovate are you using?

43.242.2 (Mend-hosted, reproduction) / 43.252.1 (self-hosted, original observation)

Problem description

When a replacementName/replacementVersion rule targets a package declared in peerDependencies, Renovate either silently drops the replacement update or leaves package.json unchanged — depending on the version range. Neither case produces a PR.

Minimal reproduction repo: https://github.com/straub/renovate-repro-replacement-peerdeps

Raw Renovate log: logs/2026-07-07-renovate-run.log

---

Bug 1: X-range peer dep ("*") — replacement update silently dropped

renovate.json:

{
  "dependencyDashboard": true,
  "packageRules": [{
    "matchDatasources": ["npm"],
    "matchDepNames": ["istanbul-instrumenter-loader"],
    "replacementName": "coverage-istanbul-loader",
    "replacementVersion": "3.0.5"
  }]
}

package.json:

{ "peerDependencies": { "istanbul-instrumenter-loader": "*" } }

Current behavior: No replacement PR, no Dependency Dashboard entry, no warning. The dep appears in packageFiles with updates with "updates": []:

{
  "depType": "peerDependencies",
  "depName": "istanbul-instrumenter-loader",
  "currentValue": "*",
  "updates": []
}

Expected behavior: PR renames istanbul-instrumenter-loader: "*" → coverage-istanbul-loader: ">=3.0.5".

Root cause:

determineNewReplacementValue() (lookup/utils.ts) calls versioningApi.getNewValue(). In versioning/npm/range.ts, the first guard in getNewValue is:

if (rangeStrategy !== 'update-lockfile' && isSemVerXRange(currentValue)) {
  return null;
}

isSemVerXRange("*") is true, so every strategy except update-lockfile returns null. The null newValue is then filtered out in lookup/index.ts:

.filter(update => update.newValue !== null || config.currentValue === null)

The replacement update is dropped entirely — updateDependency is never called.

---

Bug 2: Satisfied-range peer dep (">=x.y.z") — package.json unchanged

renovate.json:

{
  "dependencyDashboard": true,
  "packageRules": [{
    "matchDatasources": ["npm"],
    "matchDepNames": ["request"],
    "replacementName": "got",
    "replacementVersion": "14.0.0"
  }]
}

package.json:

{ "peerDependencies": { "request": ">=2.0.0" } }

Current behavior: Renovate reports branchName: "renovate/request-replacement", but package.json is unchanged. The update object has "newValue": ">=2.0.0" — identical to currentValue:

{
  "updateType": "replacement",
  "newName": "got",
  "newValue": ">=2.0.0",
  "branchName": "renovate/request-replacement"
}

Relevant log lines:

{"msg":"1 flattened updates found: request","repository":"straub/renovate-repro-replacement-peerdeps"}
{"msg":"npm.updateDependency(): peerDependencies.request = >=2.0.0","branch":"renovate/request-replacement"}
{"msg":"No package files need updating","branch":"renovate/request-replacement"}
{"msg":"No changes to package files, skipping post-upgrade tasks","branch":"renovate/request-replacement"}
{"msg":"No files to commit","branch":"renovate/request-replacement"}

No PR is created.

In the Dependency Dashboard, the update remains under "The following updates are pending. To force the creation of a PR, click on a checkbox below.", but checking that box still does not create a PR.

Expected behavior: PR renames request: ">=2.0.0" → got: ">=14.0.0".

Root cause:

getNewValue({ currentValue: ">=2.0.0", newVersion: "14.0.0", rangeStrategy: "widen" }) — since satisfiesRange("14.0.0", ">=2.0.0") is true, widen returns ">=2.0.0" unchanged. So newValue = ">=2.0.0", identical to the current value.

In manager/npm/update/dependency/index.ts, updateDependency() has an early-return guard:

const oldVersion = parsedContents[depType][depName]; // ">=2.0.0"
if (oldVersion === newValue) {                       // true
  logger.trace('Version is already updated');
  return fileContent; // exits before the upgrade.newName rename logic runs
}

request is never renamed to got in package.json.

This same early-return bug affects regular dependencies too when the pinned version equals replacementVersion — see discussion #39481 for the identical symptom with framer-motion → motion.

---

Suggested fix

The early return in updateDependency should not fire when the dependency name is changing:

// Current:
if (oldVersion === newValue) {
  logger.trace('Version is already updated');
  return fileContent;
}

// Suggested:
if (oldVersion === newValue && (!upgrade.newName || upgrade.newName === depName)) {
  logger.trace('Version is already updated');
  return fileContent;
}

For Bug 1, determineNewReplacementValue would also need to return currentValue rather than null for X-ranges when a name change is configured, so the update reaches updateDependency in the first place.