New UI results in unclear expectations in large monorepo where the task you actually want to run (at the very end) is hidden at the very bottom

[NullVoxPopuli]

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/NullVoxPopuli/limber/

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

pnpm

What operating system are you using?

Mac

Which canary version will you have in your reproduction?

n/a

Describe the Bug

Simulation of the average VSCode-terminal user

Some questions people have had:

• what did I run?
• what am I waiting on?
• did it freeze?
• why isn't it doing anything?

these questions have lead to a lack of trust in the UI and reverting to disabling the new UI entirely (thanks for enabling that!)

---

This occurs in any repo with > 10 packages -- could shrink terminal height to simulate larger repo.

Because of the order of the tasks listed in the UI, the task you actually want is at they very bottom, or hidden entirely.

For example, here:

What task did I run? If I don't have cache, I may have forgotten as its not printed anywhere.
(here I ran pnpm turbo _:lint)

And here, if ❯ pnpm turbo run start, with multiple start process, they're still all hidden at the bottom (and imagine the terminal is smaller, such as what is common for folks who use the vscode terminal) -- this is a surprising decent example for how a "flat list" is suboptimal, because I didn't initially see that there are some start tasks in the middle of the list as well. Mixing "end tasks" with "dependency tasks", is misleading / confusing.

Here I'm running for a specific app -- what command did I run?

I ran:

❯ pnpm turbo --filter ./apps/repl/ start

Expected Behavior

The top of the UI shows

• what was ran
• what the end-task is, if we're waiting to start it (such as a persistent start / dev task)

To Reproduce

run any command with > 10 dependencies

Additional context

No response

[anthonyshew]

I've had this happen to me as well but couldn't strictly decide what would be "better"?

Trying to bake down this feedback into actionables, what heuristic would you think makes the most sense for the list? What "belongs" at the top? What "belongs" at the bottom? Are there situations where you would want those heuristics to flip?

I think I've formulated my opinion on what an improved list order would look like, but want to hear your opinion first.

[wagenet]

Limitations of terminal rendering aside (a big aside, I know!) my inclination would be to have the sidebar scroll to show the current running tasks.

Thinking through use cases, there are possibly three different views I'd prefer:

• For CLI and other places we're writing to a log, you'd use the traditional view
• For jobs that have interactivity or run indefinitely the current new UI
• For local jobs that are not interactive and have a definite end, a progress-based UI which doesn't currently exist.

IIRC an early version of the new UI had a progress bar. I imagine it was removed due to space concerns.

Anyway, I want to reiterate that I love the great work you're all doing here! These are just my suggestions and not complaints.

[jaswilli]

Adding my experience with the new layout and the reasons I ultimately switched back to the old (streaming) output. Also want to stress that these aren't complaints but just personal preferences that made me decide the new shiny layout wasn't worth it for me:

• I immediately missed the ability to use the terminal buffer to scroll back or search.
• Since the new layout is always sending output to the terminal (via the spinner, etc.) it messed with my terminal's status indicator (screenshot below) so if I had the tab in the background I never actually knew if there was "real" output or not.

Showing the spinner that never goes away with the new layout:

[anthonyshew]

Appreciate the feedback, folks. Have a smaller PR here to better surface the "active" tasks to the top of the list: #8632

This doesn't necessarily answer to everything shared above but a small step forward.

[sacrosanctic]

it would benefit to actually explain the task list order, because currently, it looks random

can you also update the task list checkmark to show cache hit/miss?
miss for green check
hit for blue check

[anthonyshew]

can you also update the task list checkmark to show cache hit/miss?

This is on our minds but not sure yet how we want to implement. I'm not sure that blue/green is enough since a) color alone is not enough for colorblind users and b) blue/green doesn't inherently carry that meaning of "hit/miss". We'll be able to think of something to express this surely, just not sure what yet.

[anthonyshew]

We just shipped a refactor in 2.0.7 (#8650) that puts in-progress tasks at the top of the list, which it appears addresses the issues of the original Issue comment.

I do see other bits of feedback here in the comments (and some side-feedback in original) that are also things on our mind as we continue to iterate. If anyone feels strongly enough that you feel a separate Issue is worth creating, we're happy to take those on as well.

Thank you!

[sacrosanctic]

Would you consider letting the user provide a custom fn, I'll open an issue for this if it is viable.

({name,cacheHit,type})=>fn(...)

name: name of the task
cacheHit: boolean
status: "fail"|"success"|"running"|"long running"