agent's monorepo bump updated the root lockfile but not the nested workspace lockfiles - sibling packages installed...

TL;DR: In a monorepo, the bump is not done until every lockfile that references the package is regenerated - root and nested. Re-run the install at each workspace root (or the workspace-aware command that covers all of them), verify each lockfile changed, and add a CI check that fails when any lockfile is stale relative to its manifests.

agent's monorepo bump updated the root lockfile but not the nested workspace lockfiles - sibling packages installed stale versions

1. Find all lockfiles: list them across the repo. Expected: the root lockfile shows the new version while nested ones still pin the old one.
2. Regenerate each one: run the package manager install in each workspace, or the workspace-aware command from the root that covers all workspaces. Expected: every nested lockfile now references the bumped version.
3. Verify with the package manager's own consistency check in each workspace. Expected: all workspaces report in sync.
4. Confirm the sibling symptom is gone: fresh-install a sibling package and check the resolved version. Expected: the sibling now installs the bumped version.
5. Add a CI job that checks every lockfile against its manifests. Expected: partial bumps fail fast instead of shipping stale siblings.

Use this when

• Monorepo siblings install stale versions after a bump
• Only the root lockfile changed in the upgrade PR
• Nested workspaces keep their own lockfiles
• You need lockfile-sync coverage across workspaces

Not for this skill when

• The repo uses a single root lockfile for all workspaces - then the symptom means the workspace config is wrong, not the lockfile
• Workspaces are intentionally versioned independently - then the bump was correctly scoped
• The issue is a registry outage rather than a stale lockfile

Variant phrasings

• Monorepo nested lockfile stale
• Workspace lockfile not updated
• Sibling package installed old version
• Root bump didn't reach workspaces

Why it happens

The agent ran the bump at the repo root, and the root tooling updated the root lockfile - but nested workspaces keep their own lockfiles, and nothing in the default flow regenerates them. Each workspace then installs from its own stale lockfile, so siblings silently run the old version while the root manifest claims the bump is done.

Edge cases

• Some package managers use one root lockfile for all workspaces - confirm your layout before regenerating per workspace
• Hoisting differences per workspace can still diverge even with synced lockfiles - check the actual installed tree
• The CI check must enumerate lockfiles dynamically so newly added workspaces are covered automatically

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_qVhCHnYpaF8mQHBpIax08Q