Vercel affected-project detection rebuilds sibling directory sharing root prefix

[swheel33]

Vercel’s built-in Skip deployment for unaffected projects appears to treat a sibling workspace whose directory shares the project root prefix as affecting the project.

Reproduction

Monorepo layout:

apps/plume-vaults
apps/plume-vaults-docs

Vercel project configuration:

• Root Directory: apps/plume-vaults
• Monorepo manager: Turborepo
• enableAffectedProjectsDeployments: true
• pnpm workspace includes apps/* and packages/*
• Every workspace package has a unique name

A commit changed only:

apps/plume-vaults-docs/src/content/docs/security-and-compliance/audits.md

Despite that, Vercel created and fully built the plume-vaults deployment. The deployment API reports buildSkipped: false.

Turborepo confirms the packages are unrelated:

• turbo ls --filter=...plume-vaults-docs returns only plume-vaults-docs
• turbo ls --filter=...plume-vaults returns only plume-vaults
• plume-vaults-docs is not in the dependency closure of plume-vaults

Expected

The plume-vaults deployment should be skipped because neither its source nor any internal dependency changed.

Actual

The sibling apps/plume-vaults-docs change triggers a complete apps/plume-vaults build.

Suspected cause

The affected-project detector may be checking the root directory as a raw string prefix rather than a path-segment boundary:

apps/plume-vaults-docs
^^^^^^^^^^^^^^^^^ matches apps/plume-vaults as a string prefix

Vercel references

• Team/project: plume-network/plume-vaults
• Project ID: prj_GAecs0aPBaRYnCLdRlynjxgfneAv
• Example deployment ID: dpl_AEpqSKaFBpV8MPCdDf5EQamziq1L
• Git commit: 4412083866aa603edf2b335989bc74557be6ccf8
• Vercel build CLI: 59.0.0
• Turborepo: 2.10.5

Could the Vercel/Turborepo team confirm whether sibling root-prefix collisions are expected to be path-boundary-safe and investigate this affected-project decision?

[swheel33]

Follow-up: the initial sibling root-prefix hypothesis is disproved. The same behavior occurred for a release containing only changes under apps/nest-studio/**, which shares no path prefix with apps/plume-vaults and is neither a dependency nor a dependent of plume-vaults in Turbo’s package graph.

In GitHub Actions run 32186401530, Vercel again created and fully built the plume-vaults preview deployment even though only nest-studio was in the release changes. Deployment dpl_HKuHLZqPxmNFEVcfvec9QEqnRNC8 reports buildSkipped: false.

This points to a broader affected-project filtering failure rather than path-prefix matching. As a release-validation workaround, we are moving scope authority to the repository-pinned Turbo graph over the exact production range (turbo ls --filter="...[<validated-base-sha>]" --output=json) and using Vercel only to provide the immutable deployment artifact when Turbo marks plume-vaults affected. I will add the implementation link once the change is published.

[dgesteves]

The prefix theory doesn't hold on the turbo side, which matches your follow-up. turbo assigns a changed file to a package by path components, not string prefix: 2.10.5 compares components (is_file_in_package), and 2.11 looks up the file's ancestor directories (package.rs#L82-L113).

I rebuilt your layout (apps/plume-vaults depending on packages/ui, plus apps/plume-vaults-docs and apps/nest-studio) and ran turbo query affected --packages plume-vaults --exit-code per commit on 2.10.5 and 2.11.7. A docs-only change and a nest-studio-only change both leave plume-vaults unaffected; a packages/ui change affects it. So the extra build comes from Vercel's check, not turbo's graph.

The one documented difference between the two: Vercel treats "Changes that are not a part of the workspace definition" as global changes that "deploy all applications in the repository" (requirements). turbo maps those files (.changeset/*.md, .github/workflows/*, root CHANGELOG.md or package.json) to the root package only (package.rs#L188-L213). I checked each one, and plume-vaults stays unaffected. I'd check the full range Vercel compared, not only the release's own commits, for anything outside apps/* and packages/*.

To make Vercel act on turbo's answer, use the Ignored Build Step Vercel suggests. Wrap it so turbo's exit 2 (error) also builds:

turbo query affected --base="${VERCEL_GIT_PREVIOUS_SHA:-HEAD^1}" --packages plume-vaults --exit-code > /dev/null || exit 1

0 skips, 1 builds. If the base SHA isn't in the clone, turbo assumes everything changed and the project builds. Verified on 2.10.5 and 2.11.7. Two caveats. The HEAD^1 fallback (used on a branch's first deployment) only looks at the last commit. And builds cancelled this way still count against deployments and build slots.