Configure the Nx Cache Output Location

Juri Strumpflohner: [0:00] When we restore the cache, Nx has already some baked-in defaults. For instance, if we run the build on all the projects which would then feed our cache, we see that dist folder gets produced. [0:12] If we delete this dist folder and rerun the build again, also that dist folder would automatically be restored with its files, not just the console.log() output. This is due to the fact that Nx has some defaults such as dist, which can be at the package level at the root level, which it would automatically capture as potential output locations and therefore include in the cache.

[0:35] Assume however that we have some very custom setup. Instead of dist, we have something like custom-dist where we output our files. Let's again remove that dist folder here. Now, if we run again the build, it would execute because we did change tsconfig. The cache got invalidated. It will be run again.

[0:55] Now, let's remove the disk folder again or actually the custom disk folder, which got produced.

[1:02] Let's run the operation of the build again, which now is cache. Both tasks get read from the cache but as you can see, the disk folder, or better the custom disk folder in our case, didn't get recreated. That's because Nx doesn't know about that location and so it didn't include it into the cache itself.

[1:21] Obviously, as you can imagine, we can configure that. If you have a project.json here, which Nx has for configuring the projects, then you can change it in there. You can also go into the package.json and add a note here, which is called Nx. What we want to configure here is the various targets.

[1:40] In our case, we have the build target. You create an entry here build. We would specify the outputs directory using the outputs property, which is an array of potential output location. In this case, all we want to specify here is custom disk. Then, we give Nx some meta information of this custom output directory, which it should also include in the build.

[2:08] Let's run the build again. It creates, obviously, our custom disk. Let's remove the custom disk. Let's rerun the build, which now would pull it out of the cache. You can see it got created properly and pulled out of the cache as we would expect.

[2:25] This is one way of configuring this. If, for instance, this is the default location for all of your projects, you don't have to configure it for every single project. You can go into the nx.json and add something that is called targetDefaults. This targetDefaults properties are really handy.

[2:44] Let's assume we want to express that for all of our projects, we want to have the output for the build in a custom disk directory folder. Rather than going into the individual package.json files, we can, at the global level here, define entry for that build target.

[2:59] We can say the output's property, and specify that it should be relative to the project root of every package, and should go into such a folder that is called custom disk just as we had before. Now, an alternative to the project root would be workspace root. We could totally also say that it should be at the workspace root instead.

[3:22] Let's run the build again for all of our projects. Now, let's remove the custom disk folder to make sure that it is being re-created. Now, if we run again, you can see it gets pulled out of the cache, and also, the custom disk folder gets restored from the cache.

[3:41] You can see how specifying this at the workspace level can have the same effect, but it obviously helps reduce a lot of the configuration overhead.