r/angular • u/127001-sweet-127001 • 1h ago
Your Angular Nx dependency diagram can fail a test when the code drifts
Say your Angular workspace has feature-orders, data-access-orders and shared-ui as separate Nx projects. The feature can use both libraries. Then somebody moves a helper, and data access starts importing from the feature that uses it.
A diagram in the README still looks perfectly fine. Of course it does
One useful part of my ArchUnitTS library is that you can check the Nx project graph against that diagram:
import { nxProjectSlices } from 'archunit';
const diagram = `
@startuml
component [feature-orders]
component [data-access-orders]
component [shared-ui]
[feature-orders] --> [data-access-orders]
[feature-orders] --> [shared-ui]
@enduml`;
const violations = await nxProjectSlices(process.cwd())
.should()
.ignoringExternalDependencies()
.adhereToDiagram(diagram)
.check();
expect(violations).toEqual([]);The two intended dependencies pass. Add data-access-orders -> feature-orders and the result identifies that pair as a violation. So a refactor that reverses ownership needs a deliberate architecture change, instead of quietly making the data-access library depend on a feature.
This reads Nx's cached project graph. Generate a fresh graph before running it, and run this from the workspace root. It doesn't inspect Angular's dependency injector or what gets loaded at runtime. The diagram is an allowlist for project dependencies; it doesn't require every arrow to be used.
Free and open source: ArchUnitTS. The example uses the published archunit 2.5.5 package.

