resolving-cyclic-dependencies

Resolving Cyclic Dependencies

Overview

When resolving dependency violations by moving types or refactoring packages, always check for unused dependencies that might create cycles. Cyclic dependencies can be broken by removing unused dependencies rather than restructuring code.

The Problem

When moving types to resolve dependency violations, you may discover that the target package already depends on the source package, creating a cycle:

Package A → Package B (needs types)
Package B → Package A (unused dependency)

The Solution

Before restructuring code, check if the cycle can be broken by removing unused dependencies:

1. Check for unused dependencies: Use grep to verify if Package B actually imports anything from Package A
2. Remove unused dependencies: If Package B doesn't use Package A, remove it from package.json
3. Verify: Run pnpm install and pnpm typecheck to ensure nothing breaks

Pattern

✅ CORRECT: Remove unused dependency to break cycle

# Check if package actually uses the dependency
grep -r "@prisma-next/package-a" packages/framework/core-package-b/src

# If no matches, remove from package.json
# Then verify
pnpm install
pnpm --filter @prisma-next/package-b typecheck

❌ WRONG: Restructure code when unused dependency exists

// Don't restructure types or create workarounds
// when the cycle can be broken by removing unused dependencies

Example

When moving TypesImportSpec from @prisma-next/emitter to @prisma-next/contract:

1. Discovered cycle: @prisma-next/contract → @prisma-next/operations (needs OperationRegistry)

   • @prisma-next/operations → @prisma-next/contract (unused dependency)

2. Verified unused: grep showed @prisma-next/operations doesn't import from @prisma-next/contract

3. Removed dependency: Removed @prisma-next/contract from @prisma-next/operations/package.json

4. Verified fix: pnpm install and typechecks passed