What is a Task Pipeline
If you have a monorepo workspace (or modularized app), you rarely just run one task. Almost certainly there are relationships among the projects in the workspace and hence tasks need to follow a certain order.
Just like in the graph visualization below, the myreactapp project depends on other projects. As a result, when running the build for myreactapp, these dependencies need to most certainly be built first s.t. myreactapp can use the resulting build artifacts.
While you could manage these relationships on your own and set up custom scripts to build all projects in the proper order (e.g. first build shared-ui, then feat-products and finally myreactapp), such approach is not scalable and would need constant maintenance as you keep changing and adding projects to your workspace.
This becomes even more evident when you run tasks in parallel. You cannot just naively run all of them in the same time, but the parallelism needs to respect the order as well, such as running first the builds of the libraries and then only it can resume with the parallel building of apps etc.
Nx allows to define such task dependencies in the form of "rules", which are then followed when running tasks. There's a detailed recipe but here's the high-level overview:
1{
2 ...
3 "targetDefaults": {
4 "build": {
5 "dependsOn": ["^build", "prebuild"]
6 },
7 "test": {
8 "dependsOn": ["build"]
9 }
10 }
11}
12Older versions of Nx used targetDependencies instead of targetDefaults. targetDependencies was removed in version 16, with targetDefaults replacing its use case.
When running nx test myproj, the above configuration would tell Nx to
- Run the
testcommand formyproj - But since there's a dependency defined from
test -> build(seetest:["build"]), Nx runsbuildformyprojfirst. builditself defines a dependency onprebuild(on the same project) as well asbuildof all the dependencies. Therefore, it will run theprebuildscript and will run thebuildscript for all the dependencies.
Note, Nx doesn't have to run all builds before it starts running tests. The task orchestrator will run as many tasks in parallel as possible as long as the constraints are met.
Such rules can be defined globally in the nx.json or locally per project in the package.json or project.json.
Configure it for my own project
Learn about all the details on how to configure task pipelines in the according recipe section.