feat(Turborepo): Drop turbo.json from inference calculation

[gsoltis]

Description

• Removes turbo.json from consideration when calculating repository root. This is done so that we can do inference independent of any Turborepo considerations
• Replaces turbo check with the following logic: starting from the deepest path, if we find a multi-package repo root, select that. if we find a single-repo root, select that, unless we find an ancestor multi-package root that contains the single-repo
• Note that while nested packages are not supported, we attempt to be consistent by picking the deepest root that satisfies the above logic.
• Additional behavior change: repo root detection moved up in the verbose logging output

Testing Instructions

• Replace struct-based test with filesystem-based test showing different scenarios on disk
• Update integration tests for new behavior. Some tests now error where before they would execute, but the tests were taking advantage of turbo.json presence to nest multi-package repositories. We now detect the inner multi-package repository as the root, and if it doesn't have a turbo.json, it will error when we try to execute turbo.

Closes TURBO-1392

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
examples-cra-web	🔄 Building (Inspect)	Visit Preview	💬 Add feedback	Oct 6, 2023 7:13pm
examples-svelte-web	🔄 Building (Inspect)	Visit Preview	💬 Add feedback	Oct 6, 2023 7:13pm

9 Ignored Deployments

Name	Status	Preview	Comments	Updated (UTC)
examples-basic-web	⬜️ Ignored (Inspect)	Visit Preview		Oct 6, 2023 7:13pm
examples-designsystem-docs	⬜️ Ignored (Inspect)	Visit Preview		Oct 6, 2023 7:13pm
examples-gatsby-web	⬜️ Ignored (Inspect)	Visit Preview		Oct 6, 2023 7:13pm
examples-kitchensink-blog	⬜️ Ignored (Inspect)	Visit Preview		Oct 6, 2023 7:13pm
examples-native-web	⬜️ Ignored (Inspect)	Visit Preview		Oct 6, 2023 7:13pm
examples-nonmonorepo	⬜️ Ignored (Inspect)	Visit Preview		Oct 6, 2023 7:13pm
examples-tailwind-web	⬜️ Ignored (Inspect)	Visit Preview		Oct 6, 2023 7:13pm
examples-vite-web	⬜️ Ignored (Inspect)	Visit Preview		Oct 6, 2023 7:13pm
turbo-site	⬜️ Ignored (Inspect)	Visit Preview		Oct 6, 2023 7:13pm

[github-actions]

🟢 CI successful 🟢

Thanks

[nathanhammond]

This is done so that we can do inference independent of any Turborepo considerations

I consider this a non-goal. We absolutely need the ability to consider Turborepo in tandem with the workspace manager.

Replaces turbo check with the following logic...

We should align this logic with how each of the package managers does it, and then use turbo.json to disambiguate.

• npm: https://github.com/npm/cli/blob/68031f2ae1cd5d49b0fb263da1a7eae62712ff97/workspaces/config/lib/index.js#L666-L731
• pnpm: https://github.com/pnpm/pnpm/blob/b0df222db068a7d1abf4090e7090afa4c8224998/workspace/find-workspace-dir/src/index.ts
• berry: https://github.com/yarnpkg/berry/blob/fdfc7842938a7ded6fdaaa2b5e37784ec3cdea92/packages/yarnpkg-core/sources/Configuration.ts#L1422-L1441
• yarn: https://github.com/yarnpkg/yarn/blob/158d96dce95313d9a00218302631cd263877d164/src/config.js#L773-L797
• bun: https://github.com/oven-sh/bun/blob/0a2d490bf8cb0dbfe3ccfc936d71b33fb9c59899/src/install/install.zig#L5290-L5387

We should avoid making user-facing behavior changes for the POC in #6074.

[gsoltis]

Discussed in person:

We should align this logic with how each of the package managers does it
First goal is to get to a shared implementation, then we can iterate on details if need be. One potential change for existing Turborepo behavior is switching the order of root detection and package manager detection.

Re: goals, given other consumers, doing inference independent of turbo.json is an explicit goal. If there are supported (non-nested) scenarios with material behavior changes for Turborepo users as a result, let's add them to the unit test and we can assess.

[mehulkar]

Looks good, and the behavior change also makes intuitive sense to me!

[mehulkar]

ow come get_package_manager() is a static method and not a method on a PackageJSON type? (I can't tell from the PR if package_json is a type of just a path or something)

[gsoltis]

This is copying the existing setup, but, I suspect the original reason was that we may not have a PackageJSON instance (it's an Option).

However. The only place I can currently find where we even might not have a PackageJSON instance is here. I suspect, but haven't verified, that we can't get to this point without a PackageJSON.

I think this is a good flag for a future refactor, and I will add a TODO, but I want to keep this PR relatively simple due to the behavior change.

[mehulkar]

terminology question: what does "workspace root" in is_workspace_root_of mean?

(cc @mrmckeb @codybrouwers who are interested in defining our vocabulary also)

[gsoltis]

Comes from the existing code, but in this case, it's asking "is candidate a root workspace that includes a workspace at current.path.

[mehulkar]

It's nice to create fixtures at runtime instead of maintaining them in git, but this is also much harder to read (and can fall out of sync with the explanatory comment). Kind of wishing there was a DSL or some declarative instantiation

[gsoltis]

There might be something good for this in the Rust ecosystem. I haven't really looked.

[mehulkar]

Does this setup really reflect any kind of real world scenario or is it trying to fit a bunch of use cases into the same test? I feel like it makes for an overly complicated test 🤔 (especially standalone_monorepo inside monorepo_root)

[gsoltis]

Definitely a real-world scenario. I have parts of this setup on my machine (a mix of monorepos and single-package repos as siblings in a directory). But yes, this is also somewhat the convenience of reusing the fixture.

The nested standalone inside a monorepo piece specifically is mostly not really reflective of a real world scenario, although it does occur. It is something we have code to explicitly handle as well as being covered by the test that this test is replacing

[mehulkar]

Don't understand this one. Why is standalone not just a workspace in monorepo_root? Is it because it isn't part of the workspace config of monorepo_root?

[gsoltis]

Yes, it is not covered by the workspace globs. As a further detail, different package managers behave differently here, but AFAIK none of them consider this a fully working workspace that is part of the monorepo. Part of the reason it's under the "technically not supported" section.