Feature-gate the TUI (ghostty) so turbo can be built without it

[GourangaDasSamrat]

Goals

1. Let turborepo-lib (and turbo) be compiled with the TUI (--ui=tui) support left out entirely, via a Cargo feature.
2. Cut the turborepo-ghostty → turborepo-ghostty-sys → Zig dependency chain out of the build when that feature is off.
3. Keep behavior identical for everyone who builds normally (feature on by default) — this is purely opt-out for constrained build environments.

Non-goals

1. Not proposing to remove, replace, or redesign the TUI itself — it should stay exactly as-is for default builds.
2. Not trying to fix turborepo-ghostty-sys's Android target support or the x86_64-android TLS issue directly — this is a separate, simpler escape hatch for platforms where that vendored build doesn't work at all yet.
3. Not proposing changes to turborepo-ui's public API/behavior when the feature is on.

Background

We're packaging turbo for Termux (running turbo directly on Android, via termux-packages) and hit a build failure on turbo 2.10.1: turborepo-ghostty-sys vendors ghostty's libghostty-vt via a zig build shell-out, and:

• Its zig_target() (crates/turborepo-ghostty-sys/build.rs) only supports aarch64-linux-android and x86_64-linux-android, so armv7-linux-androideabi and i686-linux-android panic with "unsupported Rust target for vendored build".
• On x86_64-linux-android, the vendored ghostty/simdutf code needs real ELF TLS (__tls_get_addr), which Android bionic only provides at API 29+, so it fails at Termux's API 24 baseline.
  Full details/build logs: bump(main/turbo): 2.10.1 termux/termux-packages#31379.

We looked into just disabling the TUI at the Cargo level, since turborepo-ui is already cleanly gated internally (#[cfg(feature = "tui")] throughout crates/turborepo-ui/src/lib.rs). The problem: turborepo-lib's Cargo.toml forces the feature on unconditionally —

turborepo-ui = { workspace = true, features = ["tui"] }

— and its own source calls straight into TUI-only APIs with no #[cfg] of its own (panic_handler.rs: restore_terminal_on_panic, is_tui_active/set_tui_active/set_tui_inactive; run/mod.rs: tui::terminal_big_enough(), tui::run_app(), tui::TuiSender). UISender (turborepo-ui::sender) is also gated behind tui internally, but is threaded structurally as Option<UISender> through run/mod.rs, commands/run.rs, and task_graph/visitor/mod.rs with no non-TUI variant — so today there's no way to turn the feature off without breaking the build in several places, even though the underlying crate design already supports it.

Proposal

Add a real tui Cargo feature to turborepo-lib, forwarded through turbo's own Cargo.toml (mirroring the existing native-tls / rustls-tls pattern), enabled by default. When disabled:

• panic_handler.rs, run/mod.rs gate their TUI-only calls behind #[cfg(feature = "tui")].
• --ui=tui / "ui": "tui" still exists as a CLI/config option, but fails at runtime with a clear "this build of turbo was compiled without TUI support" error rather than silently not existing.
• UISender-related plumbing in run/mod.rs, commands/run.rs, and task_graph/visitor/mod.rs either gets #[cfg]-gated at each site, or UISender gains a non-TUI stub so the type stays available and the diff stays smaller — happy to go either way, whichever the team would rather maintain.
  Yes, happy to put together a PR for this — wanted to sanity-check the approach first since it touches a handful of files, and to confirm where the team would want the "TUI-only" vs "generic UI plumbing" line drawn for UISender before sending something up.

[anthonyshew]

No thanks! We're not going to add derivations of our builds for every one-off request. Great option here would be to fork!