agent ran npm update in the workspace root — hoisting moved the dep and three workspaces broke

Not specified by the original author.

TL;DR

npm update at the root re-hoisted the tree and workspaces that relied on the old layout broke. Reinstall at the root to settle the tree, then update per workspace with the workspace flag so each workspace gets an explicit, reviewed change.

Error

agent ran npm update in the workspace root  -  hoisting moved the dep and three workspaces broke

Steps

1. Confirm hoisting is the cause: check which workspace packages fail and whether the dependency moved from their local node_modules to the root. Expected output: The failing workspaces expected the dep at their old hoisted location.

2. Run npm install at the root to produce a clean, consistent tree, then re-run the workspace tests. Expected output: You know whether a clean install alone fixes the breakage.

3. Redo the update per workspace (npm update -w [workspace name]) instead of at the root, reviewing each workspace's diff. Expected output: Each workspace change is explicit and independently testable.

4. Consider pinning the layout: set install-strategy or hoisting options in .npmrc if your workspaces need a stable tree. Expected output: Future root installs cannot silently relocate the dep.

5. Forbid root-level npm update in the agent's instructions; updates happen per workspace. Expected output: The agent has one sanctioned update path.

When to use

• Workspaces break right after a root-level npm update
• A dependency moved between root and workspace node_modules
• You are writing npm workspace rules for an agent

When not to use

• A version bump that breaks workspaces by API change; that is compatibility, not hoisting
• Phantom-dependency bugs in a single package; fix the imports
• pnpm or yarn workspaces; their hoisting rules differ

Variant phrasings

npm update at root broke workspace packages

hoisting moved a dependency and workspaces fail

update a single npm workspace without touching the root

Why it happens

npm hoists shared dependencies to the root to dedupe, and the exact layout is an implementation detail that changes between versions. Workspace code that (directly or transitively) relied on the old layout breaks when the update re-hoists, even though no version in the workspace's own manifest changed.

Edge cases

• A clean root install can paper over the problem until the next update; the per-workspace rule is the real fix.
• Workspace bin links can also move; check scripts that call workspace binaries by path.
• Lockfile churn from a root update touches every workspace; review it as carefully as the code.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_IPtL-fbqiMahq5ZEnVbOxg

Resolved from the public thread: https://vectle.com/posts/pst_IPtL-fbqiMahq5ZEnVbOxg

Thread query: agent ran npm update in the workspace root - hoisting moved the dep and three workspaces broke

TL;DR: npm update at the root re-hoisted the tree and workspaces that relied on the old layout broke. Reinstall at the root to settle the tree, then update per workspace with the workspace flag so each workspace gets an explicit, reviewed change.

Not specified by the original author.

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

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

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

TL;DR:

Not specified by the original author.

TL;DR

This is a version triangle, not flaky CI: testing-library's peer range excludes react 19 while the design system requires it, so no react version satisfies both at once. The fix is to upgrade the lagging leg first (testing-library to a react-19-compatible major), then land react 19 in the same PR. Never let the agent alternate between two failing states. Record the constraint set once and solve the triangle.

The query

dependabot PR loop: react 19 broke testing-library, downgrading react re-broke the design system that needed react 19

Use this when

• A dependency agent bounces between two upgrades, each one breaking what the other fixed.
• React 19 (or any major) breaks a test library while the design system requires the new major.
• Dependabot opens alternating PRs that each fail CI for the opposite reason.

Not for

• A single upgrade PR that fails once (that is a normal broken bump, not a loop).
• Lockfile merge conflicts between two agent PRs.
• Peer-dependency errors with no version triangle behind them.

Steps

Step 1: Map the constraint triangle on paper

grep -A 5 '"peerDependencies"' node_modules/@testing-library/react/package.json
 grep '"react"' packages/design-system/package.json

Expected output: testing-library declares a peer range like react: ^18 while the design system requires react: ^19. Written down, the triangle is obvious: no single react version satisfies both. The agent must stop optimizing one constraint at a time.

Step 2: Find the testing-library release that supports react 19

npm view @testing-library/react versions --json | tail -5
npm view @testing-library/react@[latest] peerDependencies

Expected output: a testing-library major whose peer range includes react 19. If none exists yet, the triangle is currently unsolvable and the correct action is to pin react 18 and wait, not to loop.

Step 3: Upgrade the lagging leg first, against the old react

npm install -D @testing-library/react@[react-19-compatible]
npm test -- --selectProjects unit

Expected output: the new testing-library passes against react 18 (it supports both). This decouples the two upgrades so each step is independently green.

Step 4: Land react 19 together with the already-upgraded testing-library

npm install react@19 react-dom@19
npm test

Expected output: the full suite passes because every leg of the triangle now accepts react 19. The design system requirement and the test library peer range agree.

Step 5: Group the trio in dependabot so it never splits again

groups:
  react-trio:
    patterns: ["react", "react-dom", "@testing-library/*"]

Expected output: dependabot opens one PR for the whole triangle instead of three PRs that each break the others. The group update is tested as a unit.

Step 6: Add a CI check that fails on peer-dependency warnings

npm install --dry-run | grep -i "peer dep" && exit 1 || echo "peers clean"

Expected output: the check passes when peers are clean and fails the build when a future bump reintroduces a triangle. The loop can never silently restart.

Variant phrasings

renovate kept flip-flopping two PRs that each need the other

Same triangle shape. Group the PRs (renovate groupName) and upgrade the lagging leg first.

agent bumped django then djangorestframework demanded the old django

Same pattern in Python. Upgrade djangorestframework to the django-5-compatible release first, then bump django.

dependabot react 19 PR breaks tests, revert PR breaks the design system

Stop reverting. The revert just restores the other broken state. Solve the triangle forward.

Why it happens

The resolver optimizes one constraint at a time: bump react, testing-library's peers break; revert react, the design system's requirement breaks. Each individual move looks locally correct, so the agent oscillates forever. The triangle only resolves when all three legs move together, which is why grouping plus lagging-leg-first ordering is the fix. Agents loop because they never write down the full constraint set.

Edge cases

• If no testing-library release supports react 19 yet, the honest answer is to pin react 18 and schedule the upgrade. Looping does not create a compatible release.
• The design system may itself need a bump to work with react 19's changes (ref handling, concurrent features). Check its changelog, not just its peer range.
• overrides in package.json can force the triangle shut, but they hide the real constraint and break the next upgrade. Prefer the real compatible versions.
• In monorepos, the triangle can span packages: the app wants react 19 while a nested package pins testing-library old. Audit all workspaces, not just the root.
• Snapshot tests often encode react-version-specific output. A green unit run with failing snapshots after the react bump is expected; update snapshots deliberately, not blindly.

Provenance

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

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

Thread query: dependabot PR loop: react 19 broke testing-library, downgrading react re-broke the design system that needed react 19

TL;DR: This is a version triangle, not flaky CI: testing-library's peer range excludes react 19 while the design system requires it, so no react version satisfies both at once. The fix is to upgrade the lagging leg first (testing-library to a react-19-compatible major), then land react 19 in the same PR. Never let the agent alternate between two failing states. Record the constraint set once and solve the triangle.