finos / finos/architecture-as-code
Renovate fails to regenerate root lockfile for grouped multi-manifest npm patch PRs
- Dominant language
- TypeScript
- Stars
- 399
- Forks
- 138
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 38
Description
## Bug Report
### Steps to Reproduce:
1. Wait for Renovate to open a grouped `patch updates` PR that touches multiple workspace `package.json` files at once (e.g. PR #2504 — bumped 6 manifests: root + `shared/`, `calm-hub-ui/`, `calm-server/`, `calm-suite/calm-guard/docs/`, `advent-of-calm/website/`).
2. Observe the PR's CI run.
3. Try `npm ci` locally against the PR branch.
### Expected Result:
The root `package-lock.json` is regenerated to match the bumped manifests, `npm ci` succeeds, all CI checks pass.
### Actual Result:
The PR ships manifest bumps but **does not include a regenerated root `package-lock.json`**. `npm ci` fails on every workspace build job, e.g.:
```
npm error code EUSAGE
npm error `npm ci` can only install packages when your package.json and
npm error package-lock.json or npm-shrinkwrap.json are in sync.
npm error Invalid: lock file's @docusaurus/module-type-aliases@3.10.0 does not satisfy @docusaurus/module-type-aliases@3.10.1
npm error Invalid: lock file's @docusaurus/tsconfig@3.10.0 does not satisfy @docusaurus/tsconfig@3.10.1
npm error Invalid: lock file's @docusaurus/types@3.10.0 does not satisfy @docusaurus/types@3.10.1
```
On PR #2504 this produced 10 failed CI jobs (every workspace build) — see https://github.com/finos/architecture-as-code/actions/runs/26401794946/job/77715606174. The PR was closed without merging because the lockfile state is broken and there is no clean way for a reviewer to "just merge it".
### Environment:
- Renovate (`app/renovate`) on `finos/architecture-as-code`
- npm workspaces monorepo, single root `package-lock.json` covering all workspaces (incl. `calm-suite/calm-guard/docs/` etc.)
- Renovate config: [`renovate.json`](../blob/main/renovate.json)
### Additional Context:
**Root cause analysis.** Two relevant issues in `renovate.json`:
1. **`ignorePaths` lists sub-workspace lockfile paths that don't exist** in an npm-workspaces layout (no `shared/package-lock.json`, `cli/package-lock.json`, etc. — they're all consolidated into the root lockfile). It's stale config from an earlier layout and should be cleaned up.
2. **`postUpdateOptions: ["npmDedupe"]`** runs `npm dedupe` *after* install — it does not by itself drive lockfile regeneration. Renovate normally runs `npm install --package-lock-only` after manifest changes, but for **grouped multi-manifest PRs** (this `patch updates` group touched 6 manifests across 6 workspaces) it occasionally fails to regenerate the lockfile coherently, producing the manifest-vs-lockfile drift seen here.
Note that this is consistent with the AGENTS.md "Lockfile Regeneration" warning, which already documents that `npm install` against an existing `node_modules` is unreliable for this monorepo and the safe regeneration recipe is `rm -rf node_modules package-lock.json && npm install`. Renovate's in-place lockfile maintenance does not perform that recipe.
**Suggested fixes (any one of these should resolve it):**
- Add a `postUpgradeTasks` block that runs the canonical regen (`rm -rf node_modules package-lock.json && npm install`) at the repo root for any npm patch/minor group, then commits the resulting lockfile back to the PR.
- Disable grouping for npm patch/minor updates (`groupName: null` for those `matchUpdateTypes`) so each manifest change ships in its own PR — Renovate's single-manifest regen is reliable.
- Add `"rebaseWhen": "behind-base-branch"` to force Renovate to re-run on a clean base before merge.
- Remove the dead `ignorePaths` entries that reference non-existent sub-workspace lockfiles.
PRs #2502 (workflow-only digest bump), #2503 (security: only `advent-of-calm/website/package-lock.json` + `Cargo.lock`, single-manifest npm change) merged cleanly. #2504 (cross-workspace grouped npm patch) failed. #2505 (grouped minor updates) likely has the same defect and should be triaged.
Contributor guide
Assessment
This issue has not been assessed yet.