-
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
feat: Re-run dependent tasks in watch mode #7898
feat: Re-run dependent tasks in watch mode #7898
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
7 Ignored Deployments
|
This stack of pull requests is managed by Graphite. Learn more about stacking. Join @NicholasLYang and the rest of your teammates on Graphite |
🟢 Turbopack Benchmark CI successful 🟢Thanks |
🟢 CI successful 🟢Thanks |
8dcda98
to
f54abf8
Compare
16b275d
to
87e072d
Compare
f54abf8
to
4a108fe
Compare
87e072d
to
5c05818
Compare
@@ -433,6 +460,12 @@ impl RunBuilder { | |||
})) | |||
.build()?; | |||
|
|||
// If we have an initial task, we prune out the engine to only | |||
// tasks that are reachable from that initial task. | |||
if let Some(entrypoint_tasks) = &self.entrypoint_tasks { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a little hacky, but I couldn't figure out how to do this otherwise without cloning Run
and we can't implement Clone
on Run
since we have the AnalyticsHandle
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we rebuilding the original task graph each time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We might want to consider separating the Engine
from an instance of Run
. Run
isn't really meant to be reusable, but it might take a little work to make it possible to use multiple of them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think we need to work out what exactly is reusable and what is persistent across runs. Like we can reuse the same analytics handle and cache handle, but maybe not the same task graph
self | ||
} | ||
|
||
pub fn hide_prelude(mut self) -> Self { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added this because the prelude makes less sense with re-run tasks. It prints the packages in scope, but the tasks in those packages are not always run, since the task graph is pruned.
10e9bfb
to
c29cbf0
Compare
8841992
to
0adec70
Compare
c29cbf0
to
b86a547
Compare
0adec70
to
d8609f2
Compare
@@ -425,6 +448,12 @@ impl RunBuilder { | |||
})) | |||
.build()?; | |||
|
|||
// If we have an initial task, we prune out the engine to only | |||
// tasks that are reachable from that initial task. | |||
if let Some(entrypoint_package) = &self.entrypoint_package { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this will eventually need to be a set of packages, especially with debouncing and waiting for current runs to finish being cancelled or completed
b86a547
to
aac815a
Compare
14a2f79
to
df46f8a
Compare
Instead of using `--filter` in our re-running of tasks for watch mode, we instead prune the task graph to run the changed task and its dependent tasks. This has the benefit of following the task graph and not the package graph. You can verify this works by creating a task dependency relation that is not in the package graph. So, make a `ui#test` task that depends on a `docs#test` task, but don't have `ui` depend on `docs`. Then verify that when the `docs` are changed, we re-run the `ui#test` task too. Closes TURBO-2752
Instead of using `--filter` in our re-running of tasks for watch mode, we instead prune the task graph to run the changed task and its dependent tasks. This has the benefit of following the task graph and not the package graph. You can verify this works by creating a task dependency relation that is not in the package graph. So, make a `ui#test` task that depends on a `docs#test` task, but don't have `ui` depend on `docs`. Then verify that when the `docs` are changed, we re-run the `ui#test` task too. Closes TURBO-2752
Instead of using `--filter` in our re-running of tasks for watch mode, we instead prune the task graph to run the changed task and its dependent tasks. This has the benefit of following the task graph and not the package graph. You can verify this works by creating a task dependency relation that is not in the package graph. So, make a `ui#test` task that depends on a `docs#test` task, but don't have `ui` depend on `docs`. Then verify that when the `docs` are changed, we re-run the `ui#test` task too. Closes TURBO-2752
Description
Instead of using
--filter
in our re-running of tasks for watch mode, we instead prune the task graph to run the changed task and its dependent tasks. This has the benefit of following the task graph and not the package graph.Testing Instructions
You can verify this works by creating a task dependency relation that is not in the package graph. So, make a
ui#test
task that depends on adocs#test
task, but don't haveui
depend ondocs
. Then verify that when thedocs
are changed, we re-run theui#test
task too.Closes TURBO-2752