TypeScript path alias resolution (tsconfig.json paths) produces zero graph edges in monorepo #308

Environment

• codebase-memory-mcp version: 0.6.0
• Codebase: TypeScript monorepo (~10,400 files) with Cloudflare Workers, Electron app, shared packages
• Package manager: bun
• OS: macOS

Summary

When indexing a TypeScript monorepo that uses tsconfig.json path aliases (e.g., @first-recon/worker-shared), cross-package imports produce zero CALLS and IMPORTS edges in the graph. This makes the tool return confidently wrong results for any cross-package dependency analysis.

Reproduction

Setup

Our monorepo has a shared package at packages/worker-shared/ with a tsconfig.json path alias @first-recon/worker-shared. Multiple workers import from it:

// In workers/chat-worker/circuit-breaker.ts
import { generateCorrelationId } from '@first-recon/worker-shared';

Expected Behavior

MATCH (f:Function)-[:CALLS]->(g:Function {name: 'generateCorrelationId'})
RETURN f.name, f.qualified_name

Should return callers from all packages that import and call this function.

Actual Behavior

0 results. Zero CALLS edges, zero IMPORTS edges cross package boundaries.

Verified with ripgrep: rg "generateCorrelationId" --type ts -l finds 14 files across 8+ workers that import and use this function. The graph sees none of them.

Confirming query

MATCH (m:Module)-[:IMPORTS]->(n) WHERE n.name CONTAINS 'correlation' RETURN count(*)

→ 0 results.

Impact

This is not an edge case — in a monorepo architecture, cross-package imports via path aliases are the default pattern. Every worker importing from shared packages is invisible to the graph.

Practical consequences:

• Impact analysis reports zero consumers for widely-used shared utilities
• Dead code detection would flag active code as unused
• An AI agent using this tool for impact analysis would systematically undercount callers and could recommend breaking changes to shared interfaces

Additional Issues Found During Evaluation

While testing, we also found these related issues:

1. n.file and n.path properties return empty strings

File location must be reverse-engineered from n.qualified_name by stripping the project prefix and replacing dots with /. This is undocumented and breaks for files with dots in their names (e.g., some.config.ts).

2. Barrel file re-exports not followed

packages/worker-shared/src/shared/index.ts re-exports generateCorrelationId, but neither the barrel nor the re-export chain is tracked.

3. Template literal URLs not detected for HTTP_CALLS

fetchWithAuth<...>(`/api/policy-analytics/triggers${queryString ? `?${queryString}` : ''}`)

This produces zero HTTP_CALLS edges. Only static string literal URLs are detected. In React codebases using hooks with query parameters, the majority of API calls use template literals.

4. Route nodes have no outgoing edges

Route nodes exist but have zero outgoing edges, making "given route X, find its handler" impossible via Cypher. HTTP_CALLS edges only go inbound (frontend → route).

5. Non-standard Cypher dialect

• labels(n) returns empty
• type(r) returns empty
• collect() in aggregation causes JSON parse errors
• Variable-length path traversal from Route nodes returns 0 results

Evaluation Scorecard

Our recommendation: SKIP at v0.6.0, monitor for tsconfig paths resolution in future versions. The underlying engine is impressive (675K nodes, 780K edges indexed in 15.5s), but TypeScript module resolution is the blocker for monorepo adoption.

Suggested Fix Priority

1. tsconfig.json paths resolution — this alone would fix the cross-package blindspot and make the tool viable for TypeScript monorepos
2. Populate n.file property — basic usability
3. Barrel file / re-export following — needed for monorepo patterns
4. Template literal URL extraction — needed for real-world React HTTP_CALLS accuracy