Skip to main content
ArcSight

Architecture problems / Hidden Dependencies

What are hidden dependencies — and how do they surprise teams at merge time?

Hidden dependencies are structural edges the team does not expect — transitive imports, indirect config coupling, or paths that do not appear in a local diff but show up in the full module graph.

Duplicate type authorities and low fan-in / high blast-radius pairs are hidden-dependency signals — the diff looks local, the graph does not.

Install ArcSightRun arc impact in under 3 minutesSee example output (Cal.com) →

How ArcSight detects this

Many visitors land here from search — not the homepage. Run this workflow locally on your repo.

  1. 1arc impact

    Surfaces break paths your diff does not show — indirect routes and transitive reach. Example path from Cal.com proof.

    arc impact components/booking/actions/bookingActionsDocs →
  2. 2arc hotspots

    Rank modules by fan-in and downstream reach across the repo.

    arc hotspots
  3. 3arc explain

    Inbound and outbound edges on a suspect module — what am I not seeing?

    arc explain components/booking/actions/bookingActions
  4. 4arc watchPro

    Pro: keep architecture clean after merge so this problem does not return.

    arc watchDocs →
  • Run arc impact on the changed file — break paths reveal indirect routes.
  • Compare fan-in on a module with its direct import list; large gaps imply transitive hubs.
  • Inspect repository proofs for gravity centers and change-risk zones outside the PR diff.

Found the issue?

Use arc impact before you change code — structured blast radius and break paths before merge. Use arc watch (Pro) to stop the problem from returning after you fix it.

npm install -g arcsightInstall →arc impact docs →arc watch docs →

All problems · Repository proofs · Install

Why it matters

Hidden dependencies answer: what am I not seeing? They cause the “how did that break?” incident — invisible in file-level review, visible in graph analysis. Low fan-in does not mean low reach when transitive paths exist.

What it looks like in codebases

  • A feature module that transitively pulls in server-only code through a shared util.
  • Config re-exports that create indirect edges across package boundaries.
  • Test utilities imported into production paths through barrel files.

Real repository evidence

Every row below comes from an ArcSight analysis snapshot — not a template or keyword page.

Cal.com

Hidden dependency signal: duplicate type authorities (23 clusters). 23 duplicate type authorities compete across modules — a classic hidden-dependency signal. Graph evidence surfaces paths file review misses.

ArcSight traced 398 modules and 72 edges in Cal.com (apps/web).

  • duplicate type authorities23 clusters· indirect coupling via competing schemas
  • components/booking/actions/bookingActionschange-risk zone· downstream path outside PR surface
  • components/booking/actions/BookingActionsStoreProviderchange-risk zone· downstream path outside PR surface
  • app/_trpc/trpc-clientchange-risk zone· downstream path outside PR surface
  • app/(use-page-wrapper)/settings/(settings-layout)/layoutblast radius 1· HIGH
  • app/providersblast radius 1· HIGH
  • components/apps/AppPageblast radius 1· HIGH
  • components/booking/AcceptBookingButtonblast radius 1· HIGH

Inspect first: components/booking/actions/bookingActions · components/booking/actions/BookingActionsStoreProvider · app/_trpc/trpc-client

Full repository proof: /repositories/calcom/ →

What to inspect first

  • Break paths longer than two hops from your change surface.
  • Modules with high fan-in that your team does not consider part of the feature.
  • Barrel re-exports that collapse multiple subsystems into one import.

What to do next

  • Document unexpected break paths before merge — assign retest owners per hop.
  • Split barrel files that hide transitive coupling.
  • Use arc watch (Pro) after merge to catch new hidden edges early.

Install · Validation · Repository proofs