Read the full startup error trace — NestJS indicates which module or provider index is undefined. Enable verbose logging to see the instantiation order. Use NestJS Devtools for a visual dependency graph. Static analysis tools like dependency-cruiser or eslint-plugin-boundaries can catch cycles before runtime.
Read the full error stack — the index number in the error points to the problematic import in your module's imports array.
Enable verbose NestJS logging to see the module initialization sequence.
Use @nestjs/devtools-integration for a visual graph of module and provider dependencies.
Use dependency-cruiser or eslint-plugin-boundaries to enforce architectural rules and catch cycles statically.
Search your codebase for forwardRef() occurrences — each one is a known cycle that should be documented or fixed.
You have two NestJS modules, UsersModule and AuthModule, that import each other and cause the application to fail on startup. How would you identify the circular dependency and resolve it?
When you run npm run start:dev and see an error about a circular dependency in a small NestJS project, what steps do you take to locate the offending providers?
During development of a new feature, you notice that adding a new service to the PaymentsModule triggers a circular dependency error involving the OrdersModule. Walk me through how you would debug this and decide which import to refactor.
Our CI pipeline started failing with a NestJS circular dependency stack trace after merging a PR that added a shared LoggerService. How would you investigate the root cause and prevent it from recurring?
In a monorepo with dozens of NestJS microservices, circular dependencies have become hard to track. What strategies and tooling would you put in place to detect them early and keep the module graph maintainable?
Explain how you would redesign a set of interdependent modules to eliminate circular dependencies while preserving lazy loading and performance considerations.
Our organization is migrating legacy NestJS code that heavily relies on cross‑module imports, leading to many circular dependencies. How would you plan a phased refactor that minimizes downtime and aligns with long‑term architectural goals?
Discuss the trade‑offs of using forwardRef versus extracting shared functionality into a core module when trying to break circular dependencies across multiple teams.