agent ran npm update in the workspace root — hoisting moved the dep

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

Pin back to the last known-good version immediately, then move the license scan in front of the merge so a license change blocks the PR instead of being discovered after. Check the license with npm view [pkg] license on both versions to confirm the switch. The scan ran post-merge, so the copyleft code is already in your tree and every day it sits there is risk.

Error

agent's license check ran after merge; the new version switched to a copyleft license and legal flagged it

Steps

1. Confirm the license change. Run npm view [pkg] license and compare with the previously installed version (npm view [pkg]@[old] license). Expected: the new version shows a copyleft license such as GPL-3.0 while the old one showed a permissive one.
2. Find every usage. Search the codebase for imports of the package. Expected: a short list of files that depend on it, so you know the blast radius.
3. Revert to the last good version. Pin the previous version in package.json, run npm install, and run the test suite. Expected: tests pass and the lockfile points at the old version.
4. Decide the path forward. Either stay pinned, or find a permissively licensed alternative and swap the imports. Expected: a decision recorded in the PR or ticket, not just a revert.
5. Move the license gate pre-merge. Add a CI job on the upgrade PR that scans licenses against an allowlist and fails the PR on unapproved ones. Expected: a future license-switching bump fails CI before merge, never after.

Use this when

• Legal or compliance flags a dependency version after it shipped
• A package's license field changed between versions in an upgrade
• The agent's license check runs in a post-merge or nightly job instead of on the PR
• You need to revert a merged upgrade for licensing reasons

Not for this skill when

• The license did not change but the package was always copyleft - that is a policy decision, not an upgrade bug
• You are choosing a new dependency and want a license comparison - do that review before adding it
• The flag is about a transitive dependency with a dual license - read the actual license terms first

Variant phrasings

• dependency changed license to GPL after upgrade
• copyleft license slipped in through a version bump
• license check only runs after merge
• agent merged a GPL-licensed version without checking

Why it happens

Agents optimize for green CI and passing tests, and license metadata is invisible to both. If the license scan is a nightly or post-deploy job, the agent's pre-merge checklist never sees it. License changes between versions are rare enough that nobody thinks to gate on them, so the first signal is legal flagging it weeks later.

Edge cases

• Transitive deps can carry the copyleft license even when the direct dep is permissive - scan the full tree, not just direct dependencies.
• Dual-licensed packages (e.g. MIT or GPL at your option) may scan as copyleft depending on the tool - verify the actual terms before panicking.
• Some packages change license only in a README while package.json still says MIT - treat a mismatch as a red flag and confirm with the maintainers.
• Document the chosen policy (allowlist) in the repo so the next agent does not have to guess which licenses are acceptable.

Provenance

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

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

Thread query: agent's license check ran after merge; the new version switched to a copyleft license and legal flagged it

TL;DR: