turbo ls --affected shows all packages when changing files in the packages/ directory but works correctly for apps/ directory

[dagda1]

Summary

turbo ls --affected marks ALL packages as affected when changing a single file in packages/, but works correctly for changes in apps/.

Expected: Only the changed package (and its dependents) should be marked affected.

Actual: All 10 packages are marked affected.

Environment

• Turbo: 2.7.5
• pnpm: 10.x
• Structure: apps/* and packages/* workspaces

Steps to reproduce

# Change a single file in packages/component-library
git diff dev --name-only  # Shows only one changed file
TURBO_SCM_BASE=dev pnpm turbo ls --affected  # Shows all 10 packages

Investigation

I ran pnpm turbo query "query { packages { items { name directDependencies { items { name }}}}}" and noticed that packages in packages/ have a dependency on "//" (the root), while apps don't:

// packages/theme — has root dependency
{
  "name": "@myscope/theme",
  "directDependencies": {
    "items": [{ "name": "//" }]
  }
}

// apps/webapp — no root dependency
{
  "name": "@myscope/webapp",
  "directDependencies": {
    "items": [
      { "name": "@myscope/core" },
      { "name": "@myscope/theme" }
    ]
  }
}

Questions

1. Why do packages show a dependency on "//" while apps don't?
2. Is this root dependency causing all packages to be marked affected?
3. How can I fix or configure around this?

[sunnypatell]

this is a known behavior tied to how turbo builds its dependency graph, and there's likely a known bug amplifying it.

why it happens

when turbo computes --affected, it does a multi-step pipeline:

1. git diff between your base ref and HEAD
2. global file check -- if root package.json, turbo.json, or turbo.jsonc changed, turbo short-circuits and marks all packages as affected immediately
3. file-to-package mapping -- each changed file is mapped to its owning package
4. root dependency cascade -- packages with zero internal workspace dependencies get an automatic edge to the root // node in the dependency graph

step 4 is the key. in crates/turborepo-repository/src/package_graph/builder.rs, the connect_internal_dependencies function does this:

if internal.is_empty() {
    // packages with no internal deps get connected to root
    self.workspace_graph.add_edge(*node_idx, *root_idx, ());
}

so every leaf package in packages/ that doesn't depend on other workspace packages gets connected to //. when anything triggers a root-level change, all those packages cascade as affected.

the bug that's probably making this worse

there's a confirmed bug in vercel/turborepo#11144 where turbo's internal file change detection can falsely flag the root package.json as changed, even when git diff shows no changes. since root package.json is in the DEFAULT_GLOBAL_DEPS list, this triggers the "all packages affected" short-circuit.

the symptoms match your case exactly.

how to verify

run with trace logging to see what's happening under the hood:

TURBO_LOG_VERBOSITY=trace TURBO_SCM_BASE=dev pnpm turbo ls --affected 2>&1 | grep -E "changed files|global file|all packages"

if you see something like DefaultGlobalFileChanged { file: "package.json" }, that confirms bug #11144.

workarounds

1. use explicit --filter instead of --affected:

turbo ls --filter=...[dev...HEAD]

2. make sure you have full git history:

the docs warn that shallow clones cause all packages to be marked changed. in CI:

# github actions
- uses: actions/checkout@v4
  with:
    fetch-depth: 0

3. set explicit base/head refs:

TURBO_SCM_BASE=dev TURBO_SCM_HEAD=HEAD turbo ls --affected

the root dependency edge is by design

the // connection for leaf packages exists to prevent graph disconnection. packages with no internal deps would otherwise be isolated nodes that turbo can't reason about in terms of invalidation. it's a conservative choice: better to over-invalidate than miss a real dependency.

links

• turbo --affected docs
• bug #11144 -- false positive global file changes
• change mapper source
• graph builder source

[anthonyshew]

Hey both, the linked issue is fixed. In the future, please use Issues when reporting issues. Thank you!