`turbo watch` behaves unexpectedly on Windows

[ygrandgirard]

Verify canary release

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

Link to code that reproduces this issue

https://github.com/ygrandgirard/turbo-watch-windows-repo

Which canary version will you have in your reproduction?

At the time of writing, the most recent version is the latest (2.6.3) and not a canary.

Environment information

> npx turbo info
turbo 2.6.3

CLI:
   Version: 2.6.3
   Path to executable: <PROJECT_PATH>\node_modules\turbo-windows-64\bin\turbo.exe
   Daemon status: Not running
   Package manager: npm

Platform:
   Architecture: x86_64
   Operating system: windows
   WSL: false
   Available memory (MB): 5534
   Available CPU cores: 16

Environment:
   CI: None
   Terminal (TERM): unknown
   Terminal program (TERM_PROGRAM): unknown
   Terminal program version (TERM_PROGRAM_VERSION): unknown
   Shell (SHELL): unknown
   stdin: false

Expected behavior

Every task should be executed exactly once, as it does in WSL:

$ npx turbo watch build --ui=stream --log-order=grouped
turbo 2.6.3

• Packages in scope: app-a, app-b, pkg-a, pkg-b, tooling-config
• Running build in 5 packages
• Remote caching disabled
pkg-b:prebuild: cache miss, executing 7d7d6c336d324772
pkg-b:prebuild: cache miss, executing 7d7d6c336d324772
pkg-b:prebuild:
pkg-b:prebuild:
pkg-b:prebuild: > prebuild
pkg-b:prebuild: > echo "Executing pre-build step..."
pkg-b:prebuild:
pkg-b:prebuild: Executing pre-build step...

pkg-a:build: cache miss, executing 59145fce502d521a
pkg-a:build:
pkg-a:build:
pkg-a:build: > build
pkg-a:build: > echo "Building at the speed of Turbo." > output-file.txt && cat output-file.txt
pkg-a:build:
pkg-a:build: Building at the speed of Turbo.

app-b:build: cache miss, executing 2cec7ff3f71c4167
app-b:build:
app-b:build:
app-b:build: > build
app-b:build: > mkdir -p dist && echo "Your application output!" > dist/app-output.txt && echo "Application B is built!"
app-b:build:
app-b:build: Application B is built!

pkg-b:build: cache miss, executing 6036eb8cc08cb385
pkg-b:build:
pkg-b:build:
pkg-b:build: > prebuild
pkg-b:build: > echo "Executing pre-build step..."
pkg-b:build:
pkg-b:build: Executing pre-build step...

pkg-b:build: > build
pkg-b:build: > echo "Welcome to the Turboverse." > output-file.txt && cat output-file.txt
pkg-b:build:
Welcome to the Turboverse.

app-a:build: cache miss, executing 7bdc04fed33736d0
app-a:build:
app-a:build:
app-a:build: > build
app-a:build: > mkdir -p dist && echo "Your application output!" > dist/app-output.txt && echo "Application A is built!"
app-a:build:
app-a:build: Application A is built!

^C    ...Finishing writing to cache...                                                                                                                      × Watch interrupted due to signal.

Note: the code block is horizontally scrollable. This is not a copy/paste mistake on my part.

Actual behavior

Tasks are executed multiple times, some are interrupted and restarted, and some actually never run at all.
Running the command multiple times gives different results.

> npx turbo watch build --ui=stream --log-order=grouped
turbo 2.6.3

• Packages in scope: app-a, app-b, pkg-a, pkg-b, tooling-config
• Running build in 5 packages
• Remote caching disabled
pkg-b:prebuild: cache miss, executing 7d7d6c336d324772
app-b:build: cache miss, executing 5c02dd86277522ec
pkg-b:prebuild: cache miss, executing 7d7d6c336d324772
pkg-a:build: cache miss, executing ba8a04b47ca305aa
pkg-b:prebuild: cache miss, executing 7d7d6c336d324772
pkg-a:build: cache miss, executing 727d3e9db4b63423
pkg-a:build:
pkg-a:build: > build
pkg-a:build: > echo "Building at the speed of Turbo." > output-file.txt && type output-file.txt
pkg-a:build:
pkg-a:build: "Building at the speed of Turbo."
app-b:build: cache miss, executing a7d821445f40853c
app-b:build:
app-b:build: > build
app-b:build: > mkdir dist && echo "Your application output!" > dist/app-output.txt && echo "Application B is built!"
app-b:build:
app-b:build: "Application B is built!"
app-a:build: cache miss, executing a499c9396b028fac
app-a:build: cache miss, executing 9a16c5257f89ba65
app-a:build:
app-a:build: > build
app-a:build: > mkdir dist && echo "Your application output!" > dist/app-output.txt && echo "Application A is built!"
app-a:build:
app-a:build: "Application A is built!"
    ...Finishing writing to cache...                                                                                                                                              ...Finishing writing to cache...                                                                                                                                           WARNING  could not start shutdown, exiting
    ...Finishing writing to cache...                                                                                                                                           WARNING  could not start shutdown, exiting
    ...Finishing writing to cache...                                                                                                                                           WARNING  could not start shutdown, exiting
>   ...Finishing writing to cache...

Note: the code block is horizontally scrollable. This is not a copy/paste mistake on my part.

To Reproduce

• Clone the repository
• npm ci
• npx turbo watch build --ui=stream --log-order=grouped

Additional context

npx create-turbo@canary -e with-shell-commands produces code that is not fully compatible with Windows ascat and mkdir -p are not available in cmd.

[anthonyshew]

Is this a bug that you're seeing after upgrading Turborepo? Or is this happening in a new codebase?

I'm trying to figure out if this is a regression introduced in a recent PR, or a behavior you're also seeing on older versions, as well. I don't see anything in our recent commits that stands out as affecting turbo watch's behavior, but I may be missing something.

[ygrandgirard]

The codebase I am working with is currently using turbo@2.5.5 and has the same issue. It might be older though, it is harder to spot it with tui when you do not expect it.
The new thing I tried here was to run turbo watch build from a fresh version of a repository, and did not understand why the build seemingly did not respect the dependency graph.