Architecture patterns / Dependency Cycles
Draft
No indexed repository proof with published cycle evidence yet.
What are dependency cycles — and why do they block safe refactors?
A dependency cycle is a closed loop in the module graph: A depends on B depends on C depends on A. Cycles remove a safe order for changes and testing.
Trust path: Homepage → Validation → Repository proof → Dependency Cycles → Install
Why it matters
Cycles turn refactors into guesswork. Teams cannot isolate a subsystem, cannot delete dead code confidently, and cannot predict which tests prove a change. ArcSight lists cycles as risk signals in impact output.
What it looks like in codebases
- Mutual imports between utils and domain layers that grew over time.
- Barrel files that re-export across package boundaries and close a loop.
- Plugin systems where core and extension packages depend on each other.
Real repository example
No indexed exemplar yet. See Next.js repository proof for the current flagship analysis while this pattern page is in draft.
How ArcSight detects it
- Run arc scan or arc impact — cycle detection is part of structural analysis output.
- Inspect risk signals on impact results; cycles appear before merge recommendations.
- Use arc explain on modules in suspected loops to see inbound and outbound paths.
$ arc scan# Structural cycle inventory
What to inspect first
- The shortest cycle involving the module you plan to change.
- Whether the cycle crosses package or layer boundaries.
- Shared types or constants that force mutual visibility between modules.
What to do next
- Break the smallest edge in the cycle first — extract a shared interface module.
- Re-run impact after each edge removal; partial fixes can hide remaining loops.
- Hold merge when cycles touch the change surface until arc reports a clean break path.
Run ArcSight on your codebase
Install locally, run arc impact on the module you plan to change, and get structured evidence — before you merge.
npm install -g arcsightInstall →