providers declares classes that belong to this module's DI scope — NestJS instantiates them. imports lists other modules whose exported providers this module wants to use. A common mistake is adding a service class directly to imports instead of its module, which causes a cryptic startup error.
The distinction is fundamental: providers owns the classes this module is responsible for creating. imports borrows functionality from other modules by referencing the module class, never the service class directly.
providers — classes this module owns and instantiates.
imports — module classes (not service classes) that this module depends on.
If a service lives in another module, import that module and ensure it exports the service.
Adding a service directly to imports is the most common NestJS beginner mistake.
You need to add a LoggingService to a feature module. Should it go in the imports array or the providers array of @Module(), and why?
If you forget to list a service in the providers array but try to inject it in a controller, what runtime error will you see?
When you import a SharedModule that already exports a ConfigService, do you also need to list ConfigService in the providers of the consuming module?
You added AuthModule to the imports of UsersModule, but AuthService injection fails. Walk me through how you'd debug the problem.
Explain the trade‑offs between re‑exporting a provider from a shared module versus declaring it in each feature module’s providers.
A circular dependency appeared after moving a UtilityService from CoreModule to a feature module's providers. How does the imports vs providers distinction affect this issue?
Design a strategy for organizing providers and imports across dozens of microservice modules to minimize duplicate instances and startup time.
How would you refactor a legacy monolith where many modules import each other just to access a few services, considering the imports vs providers distinction?
Discuss the impact on memory usage and request‑scoped providers when a module is imported multiple times versus providing the service locally.
At a company‑wide level you need a new cross‑cutting FeatureFlagService available to all teams without tight coupling. How would you use imports, exports, and dynamic modules to achieve this while keeping the architecture clean?
When migrating from a global shared module pattern to a more granular module system, what risks arise around provider scope and import hierarchy, and how would you mitigate them?