Optimizing Nx Workspaces with the 'Affected' Command

Use advanced optimizations beyond caching for growing applications and packages within your monorepo.

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.

Table of Contents

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:11] As we add more packages and applications to our mono repo, the necessity for optimisation beyond just caching becomes important. This is where a next affected command comes in handy.

    [00:12 - 00:30] This optimisation feature involves selectively executing commands solely on the packages or applications affected by a given pull request. These commands analyse the Git history to identify the projects that have changed and subsequently execute the specified command on those projects.

    [00:31 - 00:39] The syntax for utilizing affected commands in Nx is straightforward. Let's assume we are at our base branch and we want to create a new feature.

    [00:40 - 00:50] What we usually do is branching off from our main or master branch. Let's start by creating a new feature and call it my new feature.

    [00:51 - 01:00] Here we start implementing some changes just so that we can change something in our project. Let's change the button in our shared UI library.

    [01:01 - 01:15] Now we commit this change. First to see what has changed in this PR, we can run affected command, which we can also run against the graph.

    [01:16 - 01:24] In our case it is the previous branch, which we branch off from. You feel the comparison is performed against our main or master branch.

    [01:25 - 01:31] This opens up the graph view. We can now see a new button called show affected projects.

    [01:32 - 01:45] When we click that button, we can see frontend and shared UI being highlighted. This is because shared UI got changed by our changes to the button component and our react app frontend will be affected because it uses this button.

    [01:46 - 01:54] Now let's run the build command. Instead of main branch, we are running it based on our previous branch that we branch off from, which is module 6.

    [01:55 - 02:06] We will see that it runs the shared UI build and frontend build, but not shared utils build. It is a highly effective strategy is to refrain from execute queueting commands on projects that have remained unchanged.

    [02:07 - 02:19] If you wish to personalize the base branch, you have the option to do so in the nx.json configuration file. By default it is configured to recognize either main or master, which are the typical main branches.

    [02:20 - 02:26] In this lesson, we will learn about nx.txt pipeline features and optimizing nx 's workspaces.