Implementation: How to handle nx serve failing to resolve @libs-api/api-view...

Documentation for Sessions

⚙️ Implementation: How to handle nx serve failing to resolve @libs-api/api-view...

Date: 2026-02-09
Time: 22:17:33 UTC
Session: gspace1-101.8
Agent: backend
Confidence: 95%
Status: ✅ Documented


📋 Decision Context

Question:

How to handle nx serve failing to resolve @libs-api/api-viewer in other backends?

Task: Fix nx serve cannot resolve new @libs-api/api-viewer library


🎯 Decision Made

Chosen:

Kill stale processes, run nx reset to clear daemon cache, then restart serve processes

Options Considered:

  1. Add implicitDependencies to project.json
  2. Run nx reset and restart serve processes
  3. Set runBuildTargetDependencies: true

💭 Reasoning

When a new NX library is added to tsconfig.base.json, running serve processes don't pick up the new path mapping because the NX daemon caches the project graph. The webpack dev servers that were started before api-viewer existed cannot resolve it. The solution: (1) kill stale serve processes on all ports, (2) run npx nx reset to clear the daemon's project graph cache, (3) restart serve processes which will rediscover the full project graph including api-viewer. This is an NX-specific operational issue, not a code bug. The build command (nx build) works because it rebuilds the graph each time, but serve uses a cached graph.


📁 Files Involved


🔗 Related


Auto-generated by MCP Smart Consolidation