Field Test #020b — Next.js Root Ownership Refinement

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.

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.