Analyzing & Visualizing Workspaces
To be able to support the monorepo-style development, the tools must know how different projects in your workspace depend on each other. Nx uses advanced code analysis to construct this project graph. And it gives you a way to explore it:
How the Project Graph is Built
Nx creates a graph of all the dependencies between projects in your workspace using two sources of information:
-
Typescript
importstatements referencing a particular project's path aliasFor instance, if a file in
my-apphas this code:1import { something } from '@myorg/awesome-library';Then
my-appdepends onawesome-library -
Manually created
implicitDependenciesin thenx.jsonfile.If your
nx.jsonhas this content:1{ 2 "projects": { 3 "my-app": { 4 "tags": [], 5 "implicitDependencies": ["my-api"] 6 } 7 } 8}Then
my-appdepends onmy-api
Circular Dependencies
A circular dependency is when a project transitively depends on itself. This can cause problems in the design of your software and also makes Nx's affected algorithm less effective. The lint rule, nx-enforce-module-boundaries, will produce an error if any circular dependencies are created and ensures that any import statements going across projects only import from the defined public apis in a project's root index.ts file.
When migrating a new codebase into an nx workspace, you'll likely begin to uncover existing circular dependencies. Let's look at the simplest possible circular dependency, where projectA depends on projectB and vice versa.
To resolve circular dependencies:
First, identify the import statements causing the dependency. Search in the source folder of projectA for references to @myorg/projectB and search in the source folder of projectB for references to @myorg/projectA.
Then there are three strategies you can use:
- Look for small pieces of code that can be moved from one project to the other.
- Look for code that both libraries depend on and move that code into a new shared library.
- Combine
projectAandprojectBinto one library.