You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.md
-1Lines changed: 0 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,5 @@
1
1
# Changelog
2
2
3
-
-**Added** Object-form `dependsOn` entries can now run a task in direct workspace dependency packages selected by package.json fields, e.g. `{ "task": "build", "from": ["dependencies", "devDependencies"] }`.
4
3
-**Added** First-party support for caching `vite build` with zero cache config, giving Vite projects correct cache hits out of the box ([vitejs/vite#22453](https://github.com/vitejs/vite/pull/22453)).
5
4
-**Added**[`@voidzero-dev/vite-task-client`](https://npmx.dev/package/@voidzero-dev/vite-task-client), allowing tools to report cache information to Vite Task at runtime so users do not need to configure it manually ([#441](https://github.com/voidzero-dev/vite-task/pull/441), [#454](https://github.com/voidzero-dev/vite-task/pull/454), [#449](https://github.com/voidzero-dev/vite-task/pull/449), [#450](https://github.com/voidzero-dev/vite-task/pull/450), [#458](https://github.com/voidzero-dev/vite-task/pull/458), [#431](https://github.com/voidzero-dev/vite-task/pull/431), [#459](https://github.com/voidzero-dev/vite-task/pull/459), [#472](https://github.com/voidzero-dev/vite-task/pull/472)).
6
5
-**Changed** Cached tasks now restore automatically tracked output files by default; use `output: []` to disable restoration ([#460](https://github.com/voidzero-dev/vite-task/pull/460), [#461](https://github.com/voidzero-dev/vite-task/pull/461)).
Copy file name to clipboardExpand all lines: crates/vite_task/docs/task-query.md
+10-41Lines changed: 10 additions & 41 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,17 +7,16 @@ How `vp run` decides which tasks to run and in what order.
7
7
When `vp` starts, it builds two data structures from the workspace:
8
8
9
9
1.**Package graph** — which packages depend on which. Built from `package.json` dependency fields.
10
-
2.**Task graph** — which tasks exist and their string-form`dependsOn` relationships. Built from `vite.config.*` and `package.json` scripts.
10
+
2.**Task graph** — which tasks exist and their explicit`dependsOn` relationships. Built from `vite-task.json` and `package.json` scripts.
11
11
12
12
Both are built once and reused for every query, including nested `vp run` calls inside task scripts.
13
13
14
14
### What goes into the task graph
15
15
16
-
The task graph contains a node for every task in every package. String-form
17
-
`dependsOn` declarations become edges in this graph:
16
+
The task graph contains a node for every task in every package, and edges only for explicit `dependsOn` declarations:
18
17
19
18
```jsonc
20
-
// packages/app/vite.config.*
19
+
// packages/app/vite-task.json
21
20
{
22
21
"tasks": {
23
22
"build": {
@@ -38,8 +37,6 @@ Task graph:
38
37
```
39
38
40
39
Package dependency ordering (app depends on lib) is NOT stored as edges in the task graph. Why not is explained below.
41
-
Object-form `dependsOn` entries are also not stored as global task graph edges;
42
-
they are kept on the declaring task and expanded for each query.
43
40
44
41
## What happens when you run a query
45
42
@@ -77,7 +74,7 @@ Given the package subgraph and a task name, we build the execution plan:
77
74
1. Find which selected packages have the requested task.
78
75
2. For packages that don't have it, reconnect their predecessors to their successors (skip-intermediate, explained below).
79
76
3. Map the remaining package nodes to task nodes — this gives us topological ordering.
80
-
4.Expand `dependsOn` from these tasks (may pull in tasks from outside the selected packages).
77
+
4.Follow explicit `dependsOn` edges outward from these tasks (may pull in tasks from outside the selected packages).
81
78
82
79
The result is the execution plan: which tasks to run and in what order.
83
80
@@ -172,14 +169,12 @@ The package subgraph is already a lightweight `DiGraphMap<PackageNodeIndex, ()>`
172
169
173
170
So we clone the `DiGraphMap` once and mutate the clone. We iterate the original (stable node order) while modifying the clone.
174
171
175
-
## `dependsOn` expansion
172
+
## Explicit dependency expansion
176
173
177
-
After mapping the package subgraph to tasks, we expand `dependsOn` entries.
178
-
String-form entries follow task graph edges and can pull in tasks from packages
179
-
outside the selected set.
174
+
After mapping the package subgraph to tasks, we follow explicit `dependsOn` edges from the task graph. This can pull in tasks from packages outside the selected set.
180
175
181
176
```jsonc
182
-
// packages/app/vite.config.*
177
+
// packages/app/vite-task.json
183
178
{
184
179
"tasks": {
185
180
"build": {
@@ -193,33 +188,7 @@ If you run `vp run --filter app build`, the package subgraph contains only `app`
193
188
194
189
This is intentional — `dependsOn` is an explicit declaration that a task can't run without its dependency. Ignoring it would break the build. (Users can skip this with `--ignore-depends-on`.)
195
190
196
-
Object-form entries select direct package dependencies from the declaring task:
For `app#test`, this runs `build` in direct workspace dependency packages selected
211
-
by the listed package.json fields. If a selected package lacks `build`, expansion
212
-
walks through its matching dependency edges until it finds the nearest packages
213
-
with `build`; it stops at packages that already have `build`. Supported fields
214
-
are `dependencies`, `devDependencies`, and `peerDependencies`.
215
-
216
-
Recursive expansion comes from dependency tasks declaring their own `dependsOn`
217
-
entries. For example, if `ui#build` also has `{ "task": "build", "from": "dependencies" }`,
218
-
then `tokens#build` is selected while expanding `ui#build`.
219
-
220
-
The expansion follows `dependsOn` entries, not every topological edge.
221
-
Topological ordering comes from the package subgraph — it's already baked into
222
-
the task execution graph by Stage 2.
191
+
The expansion only follows explicit edges, not topological ones. Topological ordering comes from the package subgraph — it's already baked into the task execution graph by Stage 2.
223
192
224
193
## Nested `vp run`
225
194
@@ -244,7 +213,7 @@ The nested query produces its own execution subgraph, which gets embedded inside
0 commit comments