Managing Dependencies and Optimizing Workspaces with NX's Task Pipeline

Make sure dependencies are built first before running an application using dependsOn field.

Project Source Code

Get the project source code below, and follow along with the lesson material.

Download Project Source Code

To set up the project on your local machine, please follow the directions provided in the README.md file. If you run into any issues with running the project source code, then feel free to reach out to the author in the course's Discord channel.

This lesson preview is part of the The Art of Enterprise Monorepos with Nx and pnpm course and can be unlocked immediately with a \newline Pro subscription or a single-time purchase. Already have access to this course? Log in here.

This video is available to students only
Unlock This Course

Get unlimited access to The Art of Enterprise Monorepos with Nx and pnpm, plus 70+ \newline books, guides and courses with the \newline Pro subscription.

Thumbnail for the \newline course The Art of Enterprise Monorepos with Nx and pnpm
  • [00:00 - 00:21] In this module, we are going to learn about NX's task pipeline feature to manage our dependencies and optimizing our workspace with something called affected commands. In this lesson, we are going to learn how we can make sure that the dependencies are built first before running an application using "depends on failed".

    [00:22 - 00:35] In our main React application we built so far, which we called "frontend", we have two dependencies - "shared UI" and "shared utils". Let's try and build "frontend app" without its dependencies built.

    [00:36 - 01:01] Let's delete "shared UI's" this fall to first and then we can run the start command of "frontend application". And if we try to load the page, we will encounter an error because it says that it cannot find that this fall because we didn't build the application.

    [01:02 - 01:15] Because our reliance on other local packages within the workspace essentially boils down to symbolic links to those projects. Let's up this app and try and build the "shared UI" library.

    [01:16 - 01:23] And now we can try and run our "frontend application". As you can see, now it works as expected.

    [01:24 - 01:41] To automate this process, we can leverage NX's task pipeline capabilities. By updating the "enix.json" file and specifying the commands that need to be executed within a project's dependencies, using the "depends on failed", we can ensure seamless execution.

    [01:42 - 01:52] We have to ensure that we build "shared UI first", which is known as a "built dependency". NX can be configured to handle this automatically for us.

    [01:53 - 02:09] By configuring the "enix.json" file, we can ensure that the necessary build target is set in the target defaults area. Let's add a new property here called "depends on", where we say that all builds depend on the build of the child projects or dependent projects.

    [02:10 - 02:24] This means whenever we run a build on our "frontend reactor" by using the " current" file, it will first trigger the build on its dependent projects. We can do the same for our "dev" command.

    [02:25 - 02:47] Now if we run the "build" command on the "frontend" app, it will first run " builds" of "shared UI", as well as our other dependency project "shared utils". Here the build ran successfully, and you can read it in the bottom.

    [02:48 - 03:01] It says "successfully ran target build for project frontend" and two tasks. It depends on the two other tasks are the "build" command of the "shared UI project" and "shared utils".

    [03:02 - 03:10] In this person, we learned how to configure NX's task pipeline feature to enforce the project's dependencies to be run beforehand.