Ignore stray parent lockfiles when inferring workspace root

[scarab-systems]

What?

Updates workspace root inference so a parent lockfile is only promoted above the app lockfile when it has workspace authority. Explicit pnpm-workspace.yaml roots still win, and parent package roots still win when their package.json declares workspaces.

Plain parent lockfiles and parent package roots without workspaces are ignored, so accidental home-directory lockfiles do not become the inferred Turbopack/output tracing root.

Why?

A stray parent lockfile can make Next.js infer a root that is much broader than the app, which can send Turbopack module resolution and file watching through the wrong directory tree.

At the same time, higher monorepo roots can be intentional. This keeps that behavior instead of switching to a blanket "nearest lockfile wins" rule.

How?

• Keeps pnpm-workspace.yaml as an explicit workspace root marker.
• Requires lockfile markers to have a sibling package.json.
• Requires parent lockfile markers above the nearest app marker to declare workspaces.
• Updates the existing multiple-lockfiles e2e fixture so the warning case uses a valid parent workspace marker.
• Adds unit coverage for stray parent lockfiles, non-workspace parent package roots, package workspaces, and pnpm workspace roots.

Fixes #92978

Testing

• pnpm testheadless packages/next/src/lib/find-root.test.ts
• pnpm test-dev-turbo test/e2e/app-dir/multiple-lockfiles/multiple-lockfiles.test.ts
• pnpm test-dev-turbo test/e2e/app-dir/multiple-lockfiles/multiple-lockfiles-with-turbo-root.test.ts
• pnpm test-dev-turbo test/e2e/app-dir/multiple-lockfiles/multiple-lockfiles-with-output-file-tracing-root.test.ts
• pnpm test-types
• pnpm lint-eslint packages/next/src/lib/find-root.ts packages/next/src/lib/find-root.test.ts test/e2e/app-dir/multiple-lockfiles/multiple-lockfiles.test.ts test/e2e/app-dir/multiple-lockfiles/multiple-lockfiles-with-turbo-root.test.ts test/e2e/app-dir/multiple-lockfiles/multiple-lockfiles-with-output-file-tracing-root.test.ts
• pnpm exec prettier --check packages/next/src/lib/find-root.ts packages/next/src/lib/find-root.test.ts test/e2e/app-dir/multiple-lockfiles/multiple-lockfiles.test.ts test/e2e/app-dir/multiple-lockfiles/multiple-lockfiles-with-turbo-root.test.ts test/e2e/app-dir/multiple-lockfiles/multiple-lockfiles-with-output-file-tracing-root.test.ts
• git diff HEAD^ HEAD --check

[mischnic]

This is intentionally the highest one though.
It's somewhat common for people to have /monorepo/pnpm-lock.yaml and /monorepo/apps/docs/pnpm-lock.yaml. And the correct lockfile in that case is unfortunately the higher one, not the nearer apps/docs one.

[scarab-systems]

Thanks, that makes sense. I was optimizing for the stray-parent-lockfile failure in #92978, but I see the intended monorepo case here: /monorepo/pnpm-lock.yaml can still be the correct root even when /monorepo/apps/docs/pnpm-lock.yaml exists.

I’ll revisit the patch with that invariant in mind instead of simply switching to “nearest wins.” I’ll either come back with a narrower change that distinguishes the stray-parent case from the nested-app-in-monorepo case, or update the PR if this needs a different direction.

[scarab-systems]

Following up on my note above: I reworked the PR around the narrower invariant you pointed to. The updated patch no longer makes this a blanket nearest-lockfile rule.

It keeps higher workspace roots when they are explicit (pnpm-workspace.yaml) or when a parent package.json declares workspaces, while filtering out stray parent lockfiles and non-workspace parent package roots. I also added tests for both sides: the stray-parent cases from #92978 and the valid higher-root monorepo case you called out.