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
import
statements referencing a particular project's path aliasFor instance, if a file in
my-app
has this code:import { something } from '@myorg/awesome-library';
Then
my-app
depends onawesome-library
Manually created
implicitDependencies
in thenx.json
file.If your
nx.json
has this content:1{ 2 "projects": { 3 "my-app": { 4 "tags": [], 5 "implicitDependencies": ["my-api"] 6 } 7 } 8} 9
Then
my-app
depends 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
projectA
andprojectB
into one library.