fix: Tweaks for nub support

[colinhacks]

We maintain nub and have been testing Turborepo's nub support (added in #13120 / #13169 / #13179) end-to-end against a create-turbo --package-manager nub monorepo. This carries three fixes; each is scoped to crates/turborepo-repository/src/package_manager/ and the create-turbo login hint. R1 below is a heads-up only, not a code change here.

1. Correct the create-turbo remote-cache login hint

The post-scaffold hint for nub printed nub turbo login, which errors: turbo is a project-local binary, and nub runs local binaries through nub exec (alias nubx), not as a bare nub <name> subcommand. Setting the nub executable to nub exec makes the hint read nub exec turbo login, matching the package-binary-exec form already used for the other managers (npx, pnpm dlx, yarn dlx, bunx).

2. Detect nub only via the packageManager field, not the lockfile name

detect_package_manager treated the presence of nub's native lock.yaml as a nub signal. This drops that: nub is now recognized only through the packageManager field / devEngines.packageManager. nub's lockfile name is deliberately neutral and nub is lockfile-compatible with whatever the project already uses, so the file's presence is not a reliable nub signal. Lockfile parsing is unchanged — once nub is detected via the field, PackageManager::Nub { lockfile } still parses lock.yaml through the underlying (pnpm) path; only the name-based detection is removed.

Note

Detection tradeoff: a nub project identified only by a bare lock.yaml — no packageManager field, no other recognized lockfile — is no longer detected as nub. Turborepo falls back to its normal lockfile-based detection, which finds no package manager when only lock.yaml is present. The field is written on the adoption paths that matter: the create-turbo nub template writes devEngines.packageManager, and nub pm use nub writes it when converting an existing project — so scaffolded and converted repos are covered. A hand-authored, field-less nub repo is not. We think the field is the more robust signal, but the narrower lockfile-name coverage is your call.

3. Build internal workspace edges in a nub monorepo (link_workspace_packages)

In a nub monorepo, Turborepo discovers the workspace packages but builds no internal dependency edges between them: web#build depends on nothing, where the same scaffold under pnpm or npm depends on @repo/ui#build et al. Two consequences: dependents serve stale cache after an internal package changes, and turbo prune --docker web drops the internal packages entirely (the pruned build then fails to resolve @repo/ui).

Root cause: the create-turbo nub template declares internal deps with a bare specifier ("@repo/ui": "*"), like the npm and bun templates — not "workspace:*". PackageManager::Nub delegated link_workspace_packages to its underlying lockfile format (pnpm), which defaults to false on pnpm 9, so is_internal treated every non-workspace: internal dep as external. npm, yarn, and bun all return true here, and nub links a bare specifier to the local workspace package exactly as they do (nub symlinks it and records version: link:... in its lockfile). This sets link_workspace_packages to true for nub, putting it on the same edge-resolution path as npm/bun rather than pnpm's workspace:-only default. It reuses the existing package.json dependency-splitting path — no new lockfile-graph machinery.

Reproduction on current main (turbo 2.10.3-canary.4):

# nub scaffold (before this change)
$ turbo build --dry=json | jq '.tasks[] | select(.taskId=="web#build") | .dependencies'
[]                                    # ❌ no internal edges
$ turbo prune web --docker
 - Added web                          # ❌ @repo/ui dropped

# same scaffold under npm (link_workspace_packages = true, identical "*" specifiers)
$ turbo build --dry=json | jq '.tasks[] | select(.taskId=="web#build") | .dependencies'
["@repo/eslint-config#build","@repo/typescript-config#build","@repo/ui#build"]   # ✓

The fix puts nub on that same true path, so the nub scaffold resolves identically. Covered by unit tests in package_manager/mod.rs (test_nub_links_workspace_packages_unlike_underlying_pnpm) and the detection tests in nub.rs / mod.rs. cargo test -p turborepo-repository is green (219 tests).

R1 (heads-up, not fixed here): Turbopack workspace-root inference

On a fresh nub scaffold, the first turbo build hits Next/Turbopack's own workspace-root inference, which keys off recognized lockfile names and doesn't include nub's lock.yaml, so it warns and infers the wrong root. That lives in Next's root-inference code, not this module, so it's out of scope for this PR — flagging it in case the two teams want to coordinate. The identical pnpm scaffold builds clean.

Happy to adjust any of these or split them if you'd prefer separate PRs.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[vercel]

@colinhacks is attempting to deploy a commit to the Vercel Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
turborepo-eve-agent	Canceled		Jun 30, 2026 11:24pm

[anthonyshew]

@colinhacks, can you update so history only has verified signatures? It's a requirement at our GitHub org level.