Further Optimize Your Nx Workspace with Affected Commands

Instructor: [0:00] As our monorepo grows and we get more and more packages and more applications, we might need to do more optimizations than just using caching. One of such optimizations is actually just run the commands against packages or applications that got changed in a given PR. [0:17] Nx has a way to do this by so-called affected commands. What affected commands do is basically look at the Git history, figure out the project that changed and then run the command that we specified against those. The syntax for that is basic to run Nx.

[0:37] Rather than using run-many, we run something like affected: and let's say build, or if you want to run all the tests for the affected products, we would run tests. It's basically affected and to target that we want to run it against. Now, let's simulate that quickly.

[0:55] For that purpose, I'm going to add here a myCustomFeature library. I just want to have package.json in there. Let me cd in there and do pnpm in it. This will give me a package.json. Inside that package.json, we don't need -- here -- this one. We can have a build command, a fake one, which just says build myCustomFeature.

[1:24] We want to remove that exit 1 here. We have a fake build command that would get triggered whenever we run something like affected-build. Let me commit this.

[1:35] Let's assume we are at our base branch and we want to create a new feature. Let's remember this branch, because this is custom because I'm in this example repository. Usually what you do is, you branch off your main or master branch.

[1:50] You start by creating a new feature, which is...let's call it myCustomFeature. Here, we start implementing some change. For instance, we could go to that button here that we had already before and do some console.log() in here, just to create a change in our project. Let's commit this onto our feature branch.

[2:14] To run affected command, we can also run it against the graph to first see what changed in this PR. Since by default, the comparison is being done against main or master, for this specific purpose, I'm just overriding that by specifically providing a base reference. In our case, it is the previous branch, which is 11 affected commands.

[2:39] This opens up the graph view here and now we see a new button that has a naming show effect the projects.

[2:46] What we would see here is we would just see the shared UI that got changed and that's because we change the implementation of the button, but also its dependent. My remix app would be affected because it obviously depends on this one. Changes in here might affect the top-level project as well.

[3:02] However, if you show all the projects, my custom feature didn't get retouched and so therefore it also doesn't get executed. Now, obviously, this is just to show the graph in the browser, but we can also now run the actual build. We will see that it runs the shared UI build and My remix build, but it doesn't really touch my custom feature.

[3:27] It is a very powerful approach to actually avoid running commands against products who didn't even change. If you want to customize the base branch, you can do that in the nx.json. By default, as mentioned, it is set to either detect main or master, which are the most common main branches.

[3:46] You can also go here and override default base and say, call it dev, which is your development branch, based on the pattern that you use for your git set up.