|
| 1 | +--- |
| 2 | +title: 'Continuous tasks are a huge DX improvement' |
| 3 | +slug: nx-21-continuous-tasks |
| 4 | +authors: ['Philip Fulcher'] |
| 5 | +tags: ['nx'] |
| 6 | +cover_image: /blog/images/2025-05-09/continuous-tasks.avif |
| 7 | +description: 'Learn how to use continuous tasks in Nx 21 to improve your developer experience.' |
| 8 | +youtubeUrl: https://youtu.be/AD51BKJtDBk |
| 9 | +pinned: true |
| 10 | +--- |
| 11 | + |
| 12 | +{% callout type="deepdive" title="Nx 21 Launch Week" expanded=true %} |
| 13 | + |
| 14 | +This article is part of the Nx 21 Launch Week series: |
| 15 | + |
| 16 | +- [Nx 21 Release: Continuous tasks and Terminal UI lead the way](/blog/nx-21-release) |
| 17 | +- [Introducing Migrate UI in Nx Console](/blog/migrate-ui) |
| 18 | +- [New and Improved Module Federation Experience](/blog/improved-module-federation) |
| 19 | +- **Continuous tasks are a huge DX improvement** |
| 20 | +- [A New UI For The Humble Terminal](/blog/nx-21-terminal-ui) |
| 21 | + |
| 22 | +{% /callout %} |
| 23 | + |
| 24 | +Continuous tasks are one of the most exciting features we've launched that radically improve the developer experience (DX) of your monorepo. |
| 25 | + |
| 26 | +{% toc /%} |
| 27 | + |
| 28 | +## What are continuous tasks? |
| 29 | + |
| 30 | +Many of the tasks in your workspace are finite: they run, produce an output, and shut down on their own. **Continuous tasks** are long-lived tasks: they run until interrupted by an outside input. These are tasks like serving your application or running tests in watch mode. While Nx has always supported running these tasks, you couldn't configure other tasks to depend on them. |
| 31 | + |
| 32 | +For example, you could serve your backend and frontend separately, but you couldn't easily configure your backend to be served whenever your frontend is served. There are always options like opening two separate terminals to run the tasks or setting up a specific script or task for running these in parallel. But the DX has always been lacking. |
| 33 | + |
| 34 | +Now, tasks can be marked as continuous, and other tasks can depend on them. Nx will no longer wait for these tasks to shut down before invoking the tasks that depend on them. These continuous tasks can be configured as part of a task pipeline like any other task. Let's walk through some examples of how to use these in your task pipelines. |
| 35 | + |
| 36 | +## What is a task pipeline? |
| 37 | + |
| 38 | +A [task pipeline](/concepts/task-pipeline-configuration) is a series of definitions determining how tasks depend on one another. In a monorepo, you're rarely running a single task. That task may rely on the output of another task. For example, if your application depends on a buildable design system library, the design system must be built before the application. The application's `build` task depends on the design system's `build` task. |
| 39 | + |
| 40 | +This is such a common pipeline that we include it by default when Nx workspaces are created. It's defined in your `nx.json` in `targetDefaults`: |
| 41 | + |
| 42 | +```json {% fileName="nx.json" %} |
| 43 | +{ |
| 44 | + "targetDefaults": { |
| 45 | + "build": { |
| 46 | + "dependsOn": ["^build"] |
| 47 | + } |
| 48 | + } |
| 49 | +} |
| 50 | +``` |
| 51 | + |
| 52 | +This task pipeline says that all `build` tasks depend on the `build` task of any project it depends on, also known as "descendants." The `^` indicates descendants. |
| 53 | + |
| 54 | +`targetDefaults` is where you can define task pipelines for all tasks with that name, but you can also define them at the task level. This same task pipeline could be defined on an individual project: |
| 55 | + |
| 56 | +```json {% fileName="apps/frontend/package.json" %} |
| 57 | +{ |
| 58 | + "nx": { |
| 59 | + "targets": { |
| 60 | + "build": { |
| 61 | + "dependsOn": ["^build"] |
| 62 | + } |
| 63 | + } |
| 64 | + } |
| 65 | +} |
| 66 | +``` |
| 67 | + |
| 68 | +This is a brief overview of task pipelines. Be sure to [check the docs](/recipes/running-tasks/defining-task-pipeline) for more details. |
| 69 | + |
| 70 | +But these examples configure finite tasks: tasks that start up, produce an artifact, and then shut down. How do things change when we configure continuous tasks? |
| 71 | + |
| 72 | +{% callout type="note" title="See these examples in action" %} |
| 73 | +To see these examples working in an actual workspace, be sure to [checkout the video](https://youtu.be/y1Q1QSBEsuA). |
| 74 | +{% /callout %} |
| 75 | + |
| 76 | +## Frontend serve depends on backend serve |
| 77 | + |
| 78 | +Assuming we run a `dev` target from our `frontend` project, and a `serve` target from our `api` project, we configure this on the frontend project like this: |
| 79 | + |
| 80 | +```json {% fileName="apps/frontend/package.json" %} |
| 81 | +{ |
| 82 | + "nx": { |
| 83 | + "name": "frontend", |
| 84 | + "targets": { |
| 85 | + "dev": { |
| 86 | + "dependsOn": [{ "projects": ["api"], "target": "serve" }] |
| 87 | + } |
| 88 | + } |
| 89 | + } |
| 90 | +} |
| 91 | +``` |
| 92 | + |
| 93 | +The `frontend:dev` task now depends on `api:serve`. We must also ensure the `api:serve` target is flagged as continuous. Tasks are already flagged as continuous if you're using [inferred tasks](/concepts/inferred-tasks). If your target uses an executor, you must flag those targets as continuous yourself. This is as easy as adding `continuous: true` to the target configuration like so: |
| 94 | + |
| 95 | +```json {% fileName="apps/api/package.json" %} |
| 96 | +{ |
| 97 | + "name": "api", |
| 98 | + ... |
| 99 | + "nx": { |
| 100 | + "targets": { |
| 101 | + "serve": { |
| 102 | + "continuous": true |
| 103 | + } |
| 104 | + } |
| 105 | + } |
| 106 | +} |
| 107 | +``` |
| 108 | + |
| 109 | +Now running `frontend:dev` will also result in the `api:serve` starting in parallel. If we look at the task graph using Nx Console or `nx graph`, we'll see the new task pipeline: |
| 110 | + |
| 111 | + |
| 112 | + |
| 113 | +In addition to making for a great local development experience, e2e test suites that also run `frontend:dev` will have the same experience. The frontend and backend will be served at the same time, making e2e tests easier to run locally. |
| 114 | + |
| 115 | +## Configuring custom commands as continuous |
| 116 | + |
| 117 | +So far, we've talked about tasks from Nx plugins, but what about the custom targets you've added to your project? Continuous tasks work the same way. Let's say our project has a `codegen` target that uses graphql-codegen. The configuration for this target looks like this: |
| 118 | + |
| 119 | +```json {% fileName="packages/models-graphql/package.json" %} |
| 120 | +{ |
| 121 | + "nx": { |
| 122 | + "targets": { |
| 123 | + "codegen": { |
| 124 | + "command": "npx graphql-codegen --config {projectRoot}/codegen.ts" |
| 125 | + } |
| 126 | + } |
| 127 | + } |
| 128 | +} |
| 129 | +``` |
| 130 | + |
| 131 | +This only allows for a static output, though: it runs once, produces the artifact, and shuts down. That works well for our `build` task pipeline, where we would define a task pipeline like this: |
| 132 | + |
| 133 | +```json {% fileName="apps/frontend/package.json" %} |
| 134 | +{ |
| 135 | + "nx": { |
| 136 | + "targets": { |
| 137 | + "build": { |
| 138 | + "dependsOn": ["^build", "codegen", "^codegen"] |
| 139 | + } |
| 140 | + } |
| 141 | + } |
| 142 | +} |
| 143 | +``` |
| 144 | + |
| 145 | +Any time `build` is run on a project, it also runs the `build` task for any descendants, the `codegen` task on the project itself, and `codegen` on any descendants. This ensures we have the latest version of our generated models whenever we run `build` on an application. We want that same experience for our local dev experience when serving the frontend application. |
| 146 | + |
| 147 | +First, we create a continuous version of our `codegen` target so that now our configuration looks like this: |
| 148 | + |
| 149 | +```json {% fileName="packages/models-graphql/package.json" %} |
| 150 | +{ |
| 151 | + "nx": { |
| 152 | + "name": "models-graphql", |
| 153 | + "targets": { |
| 154 | + "codegen": { |
| 155 | + "command": "npx graphql-codegen --config {projectRoot}/codegen.ts" |
| 156 | + }, |
| 157 | + "watch-codegen": { |
| 158 | + "continuous": true, |
| 159 | + "command": "npx graphql-codegen --config {projectRoot}/codegen.ts --watch" |
| 160 | + } |
| 161 | + } |
| 162 | + } |
| 163 | +} |
| 164 | +``` |
| 165 | + |
| 166 | +We have a new target called `watch-codegen` that is marked as continuous. We added the `--watch` flag to the command. Now, when we run `watch-codegen` on a project, it will watch for changes to the GraphQL schema and re-generate models. We can apply this to any project that needs it. |
| 167 | + |
| 168 | +Now we can add dependencies from our `serve` targets to depend on `watch-codegen`: |
| 169 | + |
| 170 | +```json {% fileName="apps/frontend/package.json" %} |
| 171 | +{ |
| 172 | + "nx": { |
| 173 | + "name": "frontend", |
| 174 | + "targets": { |
| 175 | + "dev": { |
| 176 | + "dependsOn": [ |
| 177 | + { "projects": ["api"], "target": "serve" }, |
| 178 | + "^watch-codegen" |
| 179 | + ] |
| 180 | + }, |
| 181 | + "serve": { |
| 182 | + "dependsOn": [{ "projects": ["api"], "target": "serve" }] |
| 183 | + } |
| 184 | + } |
| 185 | + } |
| 186 | +} |
| 187 | +``` |
| 188 | + |
| 189 | +Our frontend app may not have its own `codegen` target, so the `serve` can depend on the `^watch-codegen` descendants. |
| 190 | + |
| 191 | +And for the backend: |
| 192 | + |
| 193 | +```json {% fileName="apps/api/package.json" %} |
| 194 | +{ |
| 195 | + "nx": { |
| 196 | + "name": "api", |
| 197 | + "targets": { |
| 198 | + "serve": { |
| 199 | + "continuous": true, |
| 200 | + "dependsOn": ["watch-codegen", "^watch-codegen"] |
| 201 | + }, |
| 202 | + "codegen": { |
| 203 | + "command": "npx graphql-codegen --config {projectRoot}/codegen.ts" |
| 204 | + }, |
| 205 | + "watch-codegen": { |
| 206 | + "continuous": true, |
| 207 | + "command": "npx graphql-codegen --config {projectRoot}/codegen.ts --watch" |
| 208 | + } |
| 209 | + } |
| 210 | + } |
| 211 | +} |
| 212 | +``` |
| 213 | + |
| 214 | +Since our backend project has its own codegen target, it needs to depend on both its own `watch-codegen` and `^watch-codegen` for its descendants. |
| 215 | + |
| 216 | +## What can continuous tasks do for you? |
| 217 | + |
| 218 | +We've covered a few different scenarios here, and the [video shows them all working inside an actual workspace](https://youtu.be/y1Q1QSBEsuA). We can visualize the task graph that we've just created to see how much we've accomplished: |
| 219 | + |
| 220 | + |
| 221 | + |
| 222 | +Now, developers can run `npx nx dev frontend` and have the `api:serve` and `watch-codegen` tasks run. One command, one terminal, and they are ready to work immediately. No more fumbling through multiple terminals or creating your own solution to the problem. Nx provides the tools to improve your developer experience. |
| 223 | + |
| 224 | +What processes could you improve using continuous tasks? |
| 225 | + |
| 226 | +Learn more: |
| 227 | + |
| 228 | +- 🧠 [Nx AI Docs](/features/enhance-AI) |
| 229 | +- 🌩️ [Nx Cloud](/nx-cloud) |
| 230 | +- 👩💻 [Nx GitHub](https://github.com/nrwl/nx) |
| 231 | +- 👩💻 [Nx Console GitHub](https://github.com/nrwl/nx-console) |
| 232 | +- 💬 [Nx Official Discord Server](https://go.nx.dev/community) |
| 233 | +- 📹 [Nx Youtube Channel](https://www.youtube.com/@nxdevtools) |
0 commit comments