What about using the dependency topology here? In my use-case I'm interested in having the root web app dev server shown in position 1 and selected by default.

I'm sure there are cases where that's not the desire, but it seems to me that it would mostly be the case.

What order would you want to create?

Alphanumeric.

are you able to guarantee that every developer in the repository would want the same order?

Yes, 100%.

The logic here is very simple, any order that:

1. is deterministic
2. is easy to scan through with your eyes
3. does not "jump"

is preferable to any other.

The only scenario when the order even matters is when you have some persistent tasks in the list (because otherwise it's anyway short-living UI that can close at any moment). It means that you have some long-running jobs that you want to look at from time to time. I cannot imagine why I would want to have any logic that contradicts to the points above.

For us this is the number one UX problem with the tool. Of course it would be nice to have a way to filter the list in process, but this is another story.

@anthonyshew, what do you think?
Would happily discuss it further. :)

PS. The suggestion does not contradict to your suggestion in the thread marked as "answer". It is useful to have some kind of "view persistence" from run to run. Same probably should be true for any other "action" that you can do in tui (e.g. hide/show sidepanel).

PPS. Of course you can have a mix of long-running and short-running tasks in the list. I do not think that it is an excuse for reordering the list in process. I still would like to check results of those short-running tasks without chasing them from top to bottom of the list. Some shortcut to hide completed tasks is good alternative in my opinion. (Could be also persisted as a TUI setting locally).

@anthonyshew Multiple things make the current solution hard for developers to work with:

• Unpredictable ordering of tasks. Each time I run a small/mid-size monorepo project eg. create-t3-turbo I get a different order of tasks based on task completion time. This leads to worse DX since I need to scan all the tasks to find the one I'm interested in. The problem isn't about making different ordering but rather making it predictable between runs.
• Long-running tasks even though they are kept on the top are also in "random" order without an option to control it. I understand ordering is influenced by dependent packages that long-running tasks are waiting for.
• No option to control the default selected task. Projects with multiple long-running tasks where one is the main one are left in a "weird" state. For example, create-t3-turbo with multiple apps where some are supplementary like local OTEL or proxy and some are core that should be displayed by default like Next.

The solution to these problems is to allow the defining of a task's custom order via turbo.json and package.json

Example 1 - a single field that controls ordering behavior in turbo.json.

{
  "tasksOrder": "alphanumeric" | "dynamic", <- alphanumeric makes ordering static, dynamic is the current algorithm
}

Example 2 - more granular ordering based on nested turbo.json

// turbo.json
{
  "tasksOrder": "dynamic",
  "defaultOrder": 100 <- optional value, sets the order for all of the tasks without specified one
}

// apps/nextjs/turbo.json
{
  "extends": ["//"],
  "order": 0, <- overrides default order. Lower values are put on the top.
  "tuiDefault": true <- keeps the currently viewed task in tui to this task
}