Use the Nx Dependency Graph to Visualize your Monorepo Structure
Nx does much more to help you scale and manage a large repository than just generating code or serving apps. Behind the scenes, Nx calculates a dependency graph that is key for a variety of different optimizations. We can also visualize this dependency graph, which is a powerful tool to better understand the relationships of apps and libs within our workspace.
Instructor: [0:00] Our Nx workspace monorepo starts growing, so we still have one application and its corresponding end-to-end tasks and two libraries which are being used by that single application.
[0:10] One library here is our React Library which is specifically exporting some React components while this one here, the util formatter is more like a TypeScript utility library, which is framework agmostic and can be imported in whatever type of project you want.
[0:24] When it comes to helping to manage and scale such a monorepo workspace across various teams or across your organization, Nx goes much further than just giving recommendations on the folder structure maybe, or helping you serve and refresh the application in a browser.
[0:41] Behind the scenes, Nx understands the structure of your workspace. You create that dependency graph that understands the relationship between applications that live up here and libraries down here, or even between the libraries.
[0:54] We can see that visually by launching a visual tool that draws us the dependency graph. You can do that by running yarn nx dep-graph. If you jump over to the browser, you will see a window that opens up. Right now, it is empty. We can start selecting our project. Since we have to just a couple of ones, let's just select all of them.
[1:13] What you can see here, and you can actually scroll in and zoom in to this picture, you can see a graph of how our workspace looks like at its current state. You can see here our main application which is the store application. The applications are represented as squares.
[1:29] You can also see the corresponding end-to-end task, which has an implicit dependency on the store. Basically, it does not depend directly, but it tests store, so there exists an implicit dependency among those.
[1:39] Also, you can see the libraries, which are represented here with round corners. You can see that store right now imports the [inaudible] shared and it also imports the util formatters and they between them, they do not know each other. There is no dependency between those libraries among them.
[1:54] This dependency graph here is very useful in order to help you reason about the structure especially as the workspace grows and there are more applications and libraries, you want to know which application uses which library or whether a library is being shared across different applications.
[2:09] There are a couple of utilities on this side to help you. For instance, you have the group by folder, which right now we just have really one folder, but this gives you a visual representation of where the libraries live.
[2:21] In our example here, they live in the store folder which you can see here in that libs store folder and then we have the libraries below here. The grouping allows you to get an even better representation of your workspace.
[2:33] Also, you can filter. We can, for instance, search util formatters and we will just get this single library or also focus on a single library.
[2:42] For instance, we could go here and focus on this one, and we'll get all dependencies of this one specifically. If we would focus on a library, we would just now get the view from this library. We would see that store UI shared gets imported by store and then there's store run time. We can also exclude store run time because you're not interested and look at this single relationship.
[3:06] Right now, as you can see, there's not too much to show but as we go ahead and build all that workspace, we will explore this even further.