The first version of the patch treated the issue as a nearest-root problem.
That was too broad.
The failure in #92978 involved a stray parent lockfile causing Next.js to infer a root that was much wider than the app’s actual project boundary. For Turbopack, that can route module resolution and file watching through the wrong directory tree.
But there is also a valid monorepo case:
/monorepo/pnpm-lock.yaml
/monorepo/apps/docs/pnpm-lock.yaml
In that layout, the higher lockfile can be the correct root.
So the better rule is not:
nearest lockfile wins
or:
highest lockfile wins
The better rule is:
workspace authority wins
The updated patch now separates root markers that actually own the workspace from parent markers that are only accidental detections.
Current repair shape:
Explicit pnpm-workspace.yaml roots still win.
Parent package.json roots still win when they declare workspaces.
Plain parent lockfiles without workspace authority are ignored.
Parent package roots without workspaces are ignored.
Nested app lockfiles remain valid when no higher workspace authority exists.
That keeps the intended monorepo behavior while addressing the stray-parent-lockfile failure.
What changed
The PR now narrows root inference around workspace authority rather than lockfile distance alone.
The important distinction is:
discovered marker is not automatically root ownership
A parent lockfile can be seen by root discovery without being allowed to take over the app’s inferred root.
The patch keeps higher roots only when they provide an explicit workspace signal:
pnpm-workspace.yaml
or a parent package.json with workspaces
Everything else stays as diagnostic context, not root ownership.
Updated validation
The updated patch passed:
pnpm testheadless packages/next/src/lib/find-root.test.ts
pnpm test-types
pnpm lint-eslint packages/next/src/lib/find-root.ts packages/next/src/lib/find-root.test.ts
pnpm exec prettier --check packages/next/src/lib/find-root.ts packages/next/src/lib/find-root.test.ts
git diff HEAD^ HEAD --check
The public PR body and diff were also checked clean for private diagnostic residue.
Test coverage
The updated tests cover both sides of the boundary:
stray parent lockfiles do not hijack root inference
non-workspace parent package roots do not hijack root inference
higher package roots with workspaces still win
higher pnpm-workspace.yaml roots still win
That is the key difference from the first patch.
The first patch fixed the reported failure path.
The updated patch preserves the valid monorepo path too.
Current PR
PR: vercel/next.js#94597
Title: Ignore stray parent lockfiles when inferring workspace root
Field test outcome
This field test tightened from a simple root-distance fix into a root-ownership fix.
The boundary is now clearer:
A parent marker should not own the app root unless it carries workspace authority.
That is the difference between fixing the reported failure and preserving the larger monorepo invariant.
The resulting patch is more precise:
stray parent lockfiles are filtered
workspace roots are preserved
focused tests cover both paths
root inference no longer treats every discovered parent marker as an owner
Disclosure: This article was drafted with AI assistance from my own field-test notes, PR records, validation logs, and repair summaries. The technical work, issue analysis, patch review, and final claims were reviewed by me before publication.
