vercel / turborepo

Build system optimized for JavaScript and TypeScript, written in Rust
https://turbo.build/repo/docs
MIT License
26.21k stars 1.81k forks source link

Turbo crashes when running with tui as ui on Windows #8861

Closed espenja closed 2 months ago

espenja commented 2 months ago

Verify canary release

Link to code that reproduces this issue

https://github.com/espenja/turbo-watch-tui-failure

What package manager are you using / does the bug impact?

pnpm

What operating system are you using?

Windows

Which canary version will you have in your reproduction?

turbo 2.0.10-canary.2

Describe the Bug

When changing "ui" to "tui" in turbo.json, turbo/pnpm crashes with an error code (-1073741510) when running turbo lint or turbo watch lint.

Output after running command:

~\source\github\espenja\turbo-watch-tui-failure on  main [+] via  v20.11.0 
λ turbo lint
turbo 2.0.10-canary.2

• Packages in scope: app-a, app-b, pkg-a, pkg-b, tooling-config
• Running lint in 5 packages
• Remote caching disabled
┌ app-b#lint > cache miss, executing 4e15d3950b9d96be
│
└────>
┌ pkg-a#lint > cache miss, executing 53c24e105a1c2c93
│
│ command finished with error: command (C:\Users\username\source\github\espenja\turbo-watch-tui-failure\packages\pkg-a) C:\Users\username\App
│ Data\Local\pnpm\pnpm.exe run lint exited (-1073741510)
└────>
┌ app-a#lint > cache miss, executing 9806529b9f24373b
│
│ command finished with error: command (C:\Users\username\source\github\espenja\turbo-watch-tui-failure\apps\apps-a) C:\Users\username\AppDat
│ a\Local\pnpm\pnpm.exe run lint exited (-1073741510)
└────>
  × internal errors encountered: unable to determine why task exited

~\source\github\espenja\turbo-watch-tui-failure on  main via  v20.11.0 took 2s

The only change necessary to reproduce this error after running npx create-turbo@canary -e with-shell-command is to change "ui" to "tui" in turbo.json

Expected Behavior

Turbo runs the task without error

To Reproduce

Additional context

I tested my reproduction against different canary releases, and the first one that introduced the bug was turbo@=2.0.10-canary.1, since reverting to turbo@=2.0.10-canary.0 works.

chris-olszewski commented 2 months ago

Could you test with 2.0.10-canary.4 and see if the issue is resolved?

espenja commented 2 months ago

2.0.10-canary.4 no longer crashes the run, and seems to be working :)

espenja commented 2 months ago

Closing as fixed in 2.0.10