vx run test --affected runs the projects your branch changed and every project downstream of them. Nothing else starts, and what it skips it can explain.
DX
DX
A pull request that touches one library should not test forty apps.
--affected runs a task only in the projects a change reaches: the ones
whose files changed, and every project that depends on them.
--affected compares against a git base. Name one (--affected=main),
or let vx pick: the workspace’s affectedBase, else origin/HEAD, else
main or master, else HEAD~1. On a pull request, set
affectedBase once in vx.workspace.ts and every run agrees.
It is sugar for a filter, --filter "...[<base>]": the projects changed
since the base, and their dependents. So it combines with any other
filter, and vx show --affected lists the projects without running.
--affected decides which projects are in the run. The cache key still
decides which tasks execute. A file outside every task’s inputs, a
README say, puts its project in the set, and every task there is a hit.
vx follows the task graph, not only package.json. A task that reads
another project’s output through dependsOn is downstream of it, even
without a package dependency. So the set is what your tasks really
depend on.
vx run picks the project you stand in. Off a terminal it never waits on a picker. On GitHub Actions every task folds into its own log group. Plus colors that respect FORCE_COLOR=0, and a build edge for packages that ship as source.
One task shows everything. Fifty tasks show a line for each one that ran. CI shows every frame. Then pick a mode yourself, write a report for the PR, or open the run as a Chrome trace.
vx prune --production leaves out the workspace packages only dev dependencies pull in, and strikes them from the copied manifests and lockfile, so the image that runs your app installs frozen without them.
Turborepo, Nx and other product names are trademarks of their owners. vx is not affiliated with or endorsed by them.