update to the PR - https://dev.to/scarab-systems/field-test-020b-nextjs-root-ownership-refinement-2pfo
A severe Turbopack root-resolution failure reduced to a two-file patch: select the nearest discovered lockfile as the root owner, keep parent lockfiles as warning context, and prove the behavior with focused coverage.
Target: vercel/next.js
Issue: https://github.com/vercel/next.js/issues/92978
PR: https://github.com/docker/compose/pull/13831
Status: open, ready for review, checks green at open
Branch: scarab-systems:92978-turbopack-nearest-root
Commit: 18f6257824 on the PR head
Patch size: 2 files, +55 / -4
Files touched:
packages/next/src/lib/find-root.ts
packages/next/src/lib/find-root.test.ts
This field test targeted a root inference bug in Next.js / Turbopack.
The issue was not that Next.js could not find lockfiles.
It was finding them.
The problem was which discovered lockfile got treated as the owning workspace root.
The failure shape
In the reported case, an app lived under a directory tree where more than one lockfile could be discovered above the app directory.
That creates two different facts:
- The nearest lockfile/root marker is the most likely owner of the current app.
- A farther parent lockfile may still be useful as warning context.
Before the patch, the root inference path could select the outer parent lockfile as the inferred workspace root.
For Turbopack, that can make module resolution run through the wrong root.
The user-visible behavior in #92978 was severe dev-server failure caused by root inference pointing above the app’s actual project boundary.
So the repair was not “ignore parent lockfiles.”
The repair was:
Use the nearest discovered root marker for root selection.
Keep farther lockfiles in the warning output.
That way the tool still tells the user about the stray parent lockfile, but it does not let that stray parent marker silently own the app root.
The boundary
The core boundary here is:
discovery is not ownership.
A root-finding function can discover multiple possible markers.
But the inferred root still needs a deterministic ownership rule.
In this case:
Nearest discovered lockfile/root marker = selected root.
Farther parent lockfiles = additional detections shown in the warning.
Explicit config = still the user override path.
That keeps the model clean:
The nearest project marker owns the default root.
The parent marker remains visible.
The user can still override with turbopack.root or outputFileTracingRoot.
What changed
The patch updates root inference in find-root.ts.
The existing path already gathers lockfiles from nearest to farthest. The patch makes root selection use the first discovered entry instead of letting the outermost parent marker win.
The duplicate-lockfile warning was adjusted so it still reports the parent lockfiles, but describes them as additional detections rather than the selected root.
The test update adds focused coverage in find-root.test.ts.
The test covers a project with:
an app-level lockfile
a stray parent lockfile
nearest-lockfile root selection
warning text that still includes the parent lockfile
That is the important part: the fix does not hide the parent lockfile. It prevents it from becoming the selected root by accident.
Why the warning still matters
The parent lockfile is not useless.
If Next.js sees multiple lockfiles, users may need to know that.
There may be a stray file in a parent directory.
There may be a monorepo layout.
There may be an app nested inside a larger workspace.
There may be a legitimate reason to configure the root explicitly.
So the warning remains.
The selected root changes.
That is the repair lane:
Do not let warning context become root ownership.
Validation
The PR was prepared on a clean public branch and opened as a ready PR.
Sanity checks included:
pnpm testonly packages/next/src/lib/find-root.test.ts
Targeted Prettier check
Targeted ESLint check
git diff --check origin/canary...HEAD
COREPACK_INTEGRITY_KEYS=0 pnpm --filter=next build
Additional local Turbopack e2e checks were also run against the relevant multiple-lockfile and pnpm-workspace-root test areas.
The public diff was checked for private diagnostic residue before the PR was opened.
No SDS/Scarab/local-path/Codex residue was included in the public PR body or diff.
The PR opened green with the expected Next.js PR marker included:
That marker is part of the Next.js contribution guidance and is intentionally hidden in the rendered PR body.
PR summary
The opened PR summary is straightforward:
Prefer the nearest discovered workspace root marker when multiple lockfiles are present above an app directory.
Keep reporting parent lockfiles in the duplicate-lockfile warning.
Add unit coverage for nearest-lockfile root selection and warning text.
Field test result
This is a small patch, but the boundary is sharp.
The bug sits at the point where root discovery becomes root ownership.
Next.js needs to detect multiple lockfiles.
Turbopack needs the correct project root.
Users need to see warning context when parent lockfiles are present.
The selected root should not jump to the outer parent simply because another lockfile exists higher in the tree.
The patch keeps those concerns separate:
nearest marker selects the root
parent markers remain warning context
explicit config remains the override
focused tests cover the behavior
That is the Scarab repair shape for this field test.
Not broad churn.
Not a rewrite.
One root inference boundary.
Two source files.
Focused coverage.
Green PR.
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.
Top comments (2)
Hey, this article appears to have been generated with the assistance of ChatGPT or possibly some other AI tool.
We allow our community members to use AI assistance when writing articles as long as they abide by our guidelines. Please review the guidelines and edit your post to add a disclaimer.
Failure to follow these guidelines could result in DEV admin lowering the score of your post, making it less visible to the rest of the community. Or, if upon review we find this post to be particularly harmful, we may decide to unpublish it completely.
We hope you understand and take care to follow our guidelines going forward!
Thank you for this guidance! I have updated my field test with proper disclosures.