-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
--parallel Does not honor build dependencies #460
Comments
We've also encountered this issue in discordjs/discord.js#7175, where the CI where it errors: https://github.com/discordjs/discord.js/runs/4674304974?check_suite_focus=true Would love to help debug this further, let me know how I can help 🎉 |
@jaredpalmer I've created a repository to reproduce the issue: https://github.com/VanTanev/turborepo-reproduce-460 I would expect when running in parallel, the leafs are run in parallel, but they still honor their build deps; Instead, leaf commands will execute in parallel with commands they depend on. |
The docs do specifically say this ignores the dependency graph, but I'm struggling to see how this is useful? In the meantime is there a workaround for local development where you build your dependencies with a |
Leafs automatically run in at max parallelism with turbo. It sounds like what you want is dev to depend on its dependencies being built? |
@jaredpalmer does that work when the "build" operation however is a watch and therefore never terminates? It seemed to hang when I tried it, which would make sense as if the process doesn't exit how does it know when to move on in the dependency graph? |
So I just tested some more bits out... I've got a
The dev task does different things:
I believe this is exactly the same setup as the Turborepo kitchen-sink example uses. Here's the graph for context: If I don't use the parallel flag (
If I add the parallel flag back in (
(Note that this app is actually running correctly, and hot-reloading correctly. But always displays this error over the top). |
Sounds like what you want to do isn't the parallel flag, but rather increase the allowed concurrency so that you are able to run through all build processes first, and then accumulate long running dev processes without running out of the 10 default go-routines. So have |
@jaredpalmer I just tried that, and unfortunately it doesn't work either (though I was using |
You're welcome to use https://github.com/IPWright83/pnpm-monorepo as another example if needed. Requires pnpm, but using |
Yeah, would be great to have this fixed. Especially, if you want to execute a collection of applications during development, e.g 10-15 watchers |
We have a similar use case, we have a monorepo of libraries (currently 9) and need to run all of them in watch mode. Libraries depend on each other and their dev process is defined as Our dev task in
and we run it as Our watchers do not hang, but once all watchers are started, package A that depends on package B doesn't not seem to be aware of changes in package B, even though the declaration file definitely exists on the filesystem.
|
Since this feature is IMHO a very basic need, I don't understand how we can use Turborepo dev mode when some packages relies on others. Did someone found any workaround on this ? |
My understanding is that this currently works /fine/. You must not pass |
Ow ! I didn't understand the same thing as you. I thought that Turborepo was "waiting" for jobs to end to start the dependents one. EDIT : without the parallel mode |
|
I fixed by doing a build first (that does exit) followed by a build-watch. Then you know all the dependencies should be ready |
this would still be a cool feature to have, pseudo parallel by topological order maybe with a configurable timeout when the dependencies in some use cases this beats first running the |
I also realized this, So I try to let the But if you have a dependency graph like Nx seems planing to support a long runing task as dependency. nrwl/nx#10706 It would be nice if turborepo also supported this. |
I have watch modes with incremental rebuilds for all packages as their Because I want to run all "dev": {
"dependsOn": ["^build"],
"cache": false
} This starts all builds and after they finish, starts all watch modes. So far, so good. However, if application A depends on package B which in turn depends on package C, what I'd like to see when I save a file in package C is that C does an incremental rebuild, followed by an incremental rebuild of B, followed of an incremental rebuild of A, followed by a browser refresh (which is out of What happens instead is an incremental rebuild of package C. That's it. Is there any way to get what I want? |
@codepunkt what tech are you using here, as this is working for me... If I update |
How do you do this with filters? I have a monorepo set up with two different folders:
Every package and app has a I want to work on one app at a time, so I want to run Is there really no inbuilt way of doing this without running ALL the Edit: I had the |
I ran into the same issue where package A depends on the build (and its type definitions) of package B. So I followed the advice given here and used:
and the script without the parallel flag:
So far everything seems to start and update accordingly. |
@rwieruch I think you might end up with a race (if dependencies don't build in the correct order). That's why I've opted to do a pre-build before hand. |
Manually build `@saleor/checkout-storefront` before running `dev` to avoid "Missing module" errors due to race conditions. This is related to the following problem: vercel/turborepo#460
So if you ended here as me, let's reiterate how Turborepo dev works (and how not) because it's confusing. The workflow a developer would expect is to install modules and then run the dev script, but that's now how Turborepo works. A dev task needs two things: generate code and run watchers. From Turborepo docs:
It's confusing because Turborepo runs everything parallel, if possible. This configuration should be named --ignoreDependecyGraph
I bet many developers just run a dev task, then they see some errors, then they will rerun it, and then it magically works. That's not ideal. Turborepo suggests that we should use As I see it, there have to be two tasks run separately from the command line. Something like Because my build does not do anything special, the recommended way (for me) is always to run |
The title and description here describes the intended behavior of What's being described here is more like several feature requests put together. Something like I'm going to close this issue since it's describing the intended behavior - but rest assured that we hear the pains! |
Manually build `@saleor/checkout-storefront` before running `dev` to avoid "Missing module" errors due to race conditions. This is related to the following problem: vercel/turborepo#460
Manually build `@saleor/checkout-storefront` before running `dev` to avoid "Missing module" errors due to race conditions. This is related to the following problem: vercel/turborepo#460
Manually build `@saleor/checkout-storefront` before running `dev` to avoid "Missing module" errors due to race conditions. This is related to the following problem: vercel/turborepo#460
Manually build `@saleor/checkout-storefront` before running `dev` to avoid "Missing module" errors due to race conditions. This is related to the following problem: vercel/turborepo#460
Describe the feature you'd like to request
In the canonical example,
turbo run dev --parallel --no-cache
is used for development.However,
--parallel
will build dependent tasks in parallel too, even though those might need to be executed in dependency order.Given a graph like:
A -> B
andA -> C
And a turborepo definition like:
Running
turbo run dev --parallel --no-cache
will break on the build step, because the builds ofB
andC
depend on the build ofA
completing.Describe the solution you'd like
One possible solution is to add a parameter like
--parallel-depth=1
(default: Infinite), where only thedev
commands are executed in parallel, but deeper dependent commands are not.Describe alternatives you've considered
Removing
build
fromdev: { dependsOn }
, and executing 2 commands works:The text was updated successfully, but these errors were encountered: