watch fails with many packages and tui

[ottob]

Verify canary release

• I verified that the issue exists in the latest Turborepo canary release.

Link to code that reproduces this issue

n/a medium sized private monorepo

Which canary version will you have in your reproduction?

2.8.11-canary.5

Environment information

• turbo 2.8.11-canary.5
CLI:
   Version: 2.8.11-canary.5
   Path to executable: /Users/ottob/dev/turbo-mono/node_modules/.bun/turbo-darwin-arm64@2.8.11-canary.5/node_modules/turbo-darwin-arm64/bin/turbo
   Daemon status: Running
   Package manager: bun

Platform:
   Architecture: aarch64
   Operating system: macos
   WSL: false
   Available memory (MB): 2884
   Available CPU cores: 8

Environment:
   CI: None
   Terminal (TERM): xterm-256color
   Terminal program (TERM_PROGRAM): Apple_Terminal
   Terminal program version (TERM_PROGRAM_VERSION): 455.1
   Shell (SHELL): /bin/zsh
   stdin: false

Expected behavior

Successful build and watch of all packages (around 50).

Im starting with turbo with: turbo watch build --filter=./packages/*

Actual behavior

After some seconds it aborts with

$ bun run clean && tsc
$ rm -rf dist
└─ @repo/payments#build ──
    ...Finishing writing to cache...                                                                    ...Finishing writing to cache...                                                                    ...Finishing writing to cache...                                                                    ...Finishing writing to cache...                                                                    ...Finishing writing to cache...  
 × Could not connect to UI thread: some packages changed: Failed to send event to TUI: channel
  │ closed

error: script "watch:packages" exited with code 1

If I run the same command again it builds more packages, and then after some tries, the builds are complete and it starts watching.

To Reproduce

1. bun run turbo daemon clean
2. turbo watch build --filter=./packages/*

I can temporarily invite somebody to our repository.

Additional context

turbo.json

{
  "$schema": "https://turborepo.com/schema.json",
  "ui": "tui",
  "concurrency": "100%",
  "tasks": {
    "//#format-and-lint": {
      "dependsOn": ["//#lint", "//#format"]
    },
    "//#format-and-lint:fix": {
      "dependsOn": ["//#lint:fix", "//#format:fix"]
    },
    "//#lint": {},
    "//#lint:fix": {},
    "//#format": {},
    "//#format:fix": {},
    "build": {
      "dependsOn": ["^build"],
      "inputs": ["$TURBO_DEFAULT$", ".env*"],
      "outputs": ["dist/**", ".next/**", "!.next/cache/**"]
    },
    "clean": {
      "cache": false
    },
    "test": {
      "dependsOn": ["^build"]
    },
    "lint": {
      "dependsOn": ["^lint"]
    },
    "check-types": {
      "dependsOn": ["^check-types"]
    },
    "dev": {
      "cache": false,
      "persistent": true
    }
  }
}

[anthonyshew]

Thanks for opening this issue!

To help us investigate, could you provide a minimal reproduction? This is a simplified example that demonstrates the problem in isolation.

A good reproduction is:

• A public GitHub repository with the minimum amount of code to reproduce the issue
• Clear steps to follow (e.g., "run turbo build, observe error")
• Free of unrelated dependencies, environment variables, or configuration

You can use npx create-turbo@latest -e with-shell-commands to quickly scaffold a fresh monorepo.

Without a reproduction, we may not be able to investigate this issue.

Thank you!

This is an AI-generated response.

[ottob]

To help us investigate, could you provide a minimal reproduction? This is a simplified example that demonstrates the problem in isolation.

Sorry, I dont think that's possible. But I can probably invite you to our repo if you want to reproduce it.

[anthonyshew]

I appreciate that but we need a minimal reproduction. Making one helps us to understand the specific source of the problem. It could be that this happens with any turbo watch invocation, for instance, which would show up on a repo like npx create-turbo@latest -e with-shell-commands. It could be that the size of your repo really is the confounding factor. It could be something specific in your repo causing this behavior. Finding out what the minimal reproduction is helps us to center on the problem.

[robMolloy]

hi @ottob I was experiencing the exact same issue, but with a type-checking command called tsc And I've managed to fix by removing the depends on flag in the turbo.json file.

Unfortunately I'm not familiar enough with the workings of TurboRepo to decide if this is a bug or the correct functionality, but it was very confusing and if it's the correct functionality I believe there should be a change in order to make it easier to understand.

In theturbo.json file I had the following.

{
  "$schema": "https://turborepo.dev/schema.json",
  "ui": "tui",
  "tasks": {
    "tsc": { 
       "dependsOn": ["^tsc"]
    }
  }
}

By removing the dependsOn Flag, it now works again.

{
  "$schema": "https://turborepo.dev/schema.json",
  "ui": "tui",
  "tasks": {
    "tsc": {}
  }
}

[robMolloy]

Just FYI, this only seems to happen when a local package is being used within another package or app.