Refactor: How to fix the circular dependency between vitto-hub and vit...

Documentation for Sessions

♻️ Refactor: How to fix the circular dependency between vitto-hub and vit...

Date: 2026-03-02
Time: 21:27:25 UTC
Session: gspace1-165.14
Agent: angular
Confidence: 95%
Status: ✅ Documented


📋 Decision Context

Question:

How to fix the circular dependency between vitto-hub and vitto-maker?

Task: Fix circular dependency vitto-hub ↔ vitto-maker


🎯 Decision Made

Chosen:

Extract VittoApiService and BrainContextService into new @libs-ai/vitto-core library. Both vitto-hub and vitto-maker now depend on vitto-core (one-directional). Vitto-hub re-exports both services for backward compatibility. Updated 6 files in vitto-maker, 1 in knowledge-graph, 1 in vitto-chat to import from vitto-core instead of vitto-hub.

Options Considered:

  1. Extract shared services to @libs-ai/vitto-core (chosen)
  2. Move route to the app level (breaks lazy loading pattern)
  3. Merge vitto-maker into vitto-hub (defeats purpose of separate lib)

💭 Reasoning

The cycle was: vitto-hub →(lazy route)→ vitto-maker →(VittoApiService, BrainContextService)→ vitto-hub. NX tracks lazy imports in the dependency graph, creating a cycle. Fix: extract the shared services to a leaf library (vitto-core) with no upstream dependencies. Both consumers import from vitto-core. Vitto-hub keeps re-exports for backward compat (32 internal components still use relative imports to the local files, which remain in place). Only external consumers (vitto-maker, knowledge-graph, vitto-chat) were updated to use @libs-ai/vitto-core. This is the minimum-blast-radius fix that breaks the cycle without touching 32+ internal files.


📁 Files Involved


🔗 Related


Auto-generated by MCP Smart Consolidation