A persistent task cannot depend on it about turbo

[anthonyshew]

This is expected behavior as documented. You can't depend on a long-running task because it won't exit.

Some options for what you may be trying to achieve:

• turbo watch allows a task to be dependency-aware. Note that this comes with the caveat that two long-running tasks still won't be able to depend on each other.
• Remove the dependsOn relationship between the tasks so that they can run in parallel, as you've mentioned is the behavior you're looking for. You might also add a "sleep 5 && your-command" to delay the startup invocation of the script that needs to wait.

Ultimately, there's no way for Turborepo to associate the runtime behavior of your tasks against each other. That would be a brand new construct that would need a champion, an RFC, and community backing so we know people want it. If you're interested in writing that idea down for the community, you can open a Discussion with the Idea label so we can all chat about it more.

[anthonyshew]

That's a description of the runtime behavior, rather than the task graphing behavior.

The tasks can indeed run at the same time, as parallelism is the default behavior of Turborepo. If you see tasks that are blocking each other and you don't want them to, you would remove their relationship in the Task Graph.

[TheKnarf]

Ultimately, there's no way for Turborepo to associate the runtime behavior of your tasks against each other

There is no reason for why it would need to. If task b depends on task a and both are persistent then just run both of them in parallell at the same time, how is that not the logical way to do it?

Nevertheless I've created a discussion for it if thats the correct forum to discuss this.

[anthonyshew]

Remove the dependsOn relationship between the tasks so that they can run in parallel, as you've mentioned is the behavior you're looking for. You might also add a "sleep 5 && your-command" to delay the startup invocation of the script that needs to wait.

Can you explain how that's different from what I've described here? What you're describing is the default behavior.

[TheKnarf]

Can you explain how that's different from what I've described here? What you're describing is the default behavior.

I'll try my best to explain since it seems that we have a bit of a miss-communication.

The point of turborepo is to build up a dependency graph automatically for a monorepo context. If I have a task called build with some dependencies and a package called package-b that depends on other packages in my monorepo, then when I run a command like pnpm turbo --filter package-b build its turborepo's job to figure out which other packages package-b depends on and run their build task as well. It does this "automatically" meaning that won't have to manually build up a list of dependencies like I might need to do if I instead was using a Makefile. Hopefully we agree that thats the point of turborepo, its a smarter alternative to Makefiles with some built inn caching options.

With the introduction of "persistent tasks" I would like for turborepo to still do its job building up a dependency graph and running all of the task that depends on each other. This however turborepo can't currently do, which you claim is by design. That means that turborepo servs zero purposes over a Makefile, even worse, I'm no forced to create a Makefile just for "persistent tasks" where I manually group tasks together that are supposed to run together across the monorepo.

Mind you I was already doing this manually before the introduction of "persistent tasks" to turborepo, but I had hoped now that turborepo got "persistent tasks" that I would no longer have to do this kind of double bookkeeping where turborepo can build a dependency graph only for "non-persistent tasks" but I myself still have to maintain this on the side.

When I first heard that turborepo was getting built inn support for "persistent tasks" I imagined that it would work as following:

Should column be able to depend on row	Persistent task	Non-persistent task
Persisten task	Yes, run both in parallell	No, the persistent task will never finish before the non-persistent task gets to run
Non-persistent task	Yes, run the non-persistent task first and then the persisten task	Yes, run the non-persistent task first before the other non-persistent task

That way instead of having a Makefile where I manually keep a list of "persistent tasks" that need to run together I could simply use turborepo as I do for "non-presistent tasks"

[anthonyshew]

Tasks that run in parallel are, by definition, not depending on each other. If you want to run them in parallel, you would remove the dependsOn relationship.

[TheKnarf]

Tasks that run in parallel are, by definition, not depending on each other. If you want to run them in parallel, you would remove the dependsOn relationship.

I don't agree with you. For example a Frontend app would depend on the api from the Backend app, therefor in a dev setting (persistent task) they would both need to run at the same time.

[TheKnarf]

That's a description of the runtime behavior, rather than the task graphing behavior.

Persistent tasks are runtime behavior.

It is my opinion that dependsOn for persistent tasks should work the same way that depends_on work in a Docker Compose file.

[mangobestfruit]

@TheKnarf I think you can do what you're looking for with the filtering syntax https://turbo.build/repo/docs/reference/run#microsyntaxes-for-filtering

In your example you'd do something like turbo run dev --filter=package-b... to also run dev on all the dependencies of package-b