How does NestJS resolve constructor injection at runtime?
TypeScript emits constructor parameter types as metadata via emitDecoratorMetadata: true in tsconfig. NestJS reads this using the reflect-metadata package to determine what tokens to inject. It then looks up those tokens in the module's provider registry and resolves the dependency graph recursively before instantiating the class.
NestJS leverages TypeScript's metadata reflection system to automatically detect constructor dependencies. When a class is decorated with @Injectable(), TypeScript emits type metadata that NestJS reads at runtime.
- 1
TypeScript emits design:paramtypes metadata for decorated classes.
- 2
NestJS reads this metadata using Reflect.getMetadata().
- 3
Each type is used as a DI token to look up a registered provider.
- 4
The container resolves the full dependency graph before instantiating any class.
Scenario Questions
0-2 years experience
- 1You need to inject a service into a controller in NestJS. Walk me through what happens when the app starts and how NestJS knows which instance to provide.
- 2If you forget to add a provider to the module's providers array, what runtime error will you see when trying to inject it via the constructor?
- 3How would you inject a plain config object using a value provider and constructor injection?
2-5 years experience
- 1During a feature rollout, a newly added dependency is always undefined in the constructor despite being listed in providers. How would you debug the injection resolution process?
- 2Explain the trade‑offs between using the default (singleton) scope and a request‑scoped provider when resolving constructors.
- 3You need to inject two implementations of the same interface into a service. How does NestJS let you differentiate them at runtime, and what changes are required in the constructor?
5-8 years experience
- 1Our microservice suite shares a common library of providers compiled separately. What considerations ensure constructor injection works correctly across those apps?
- 2We observed a memory leak after many requests; investigation points to provider lifecycles. How would you determine if runtime constructor resolution is a factor and what design changes could mitigate it?
- 3When integrating a third‑party library that uses its own DI container, how would you expose its objects so they can be injected via NestJS constructors without breaking the resolution flow?
8+ years experience
- 1We plan to migrate a large monolith to a modular NestJS codebase. How would you design provider registration and injection strategy to keep constructor resolution performant and maintainable across dozens of modules?
- 2Across multiple teams, some services need to be overridden for specific deployments (e.g., mocks). What patterns allow runtime substitution of injected constructors while preserving type safety?
- 3Considering a future shift to serverless, how does NestJS's runtime injection mechanism affect cold‑start latency, and what architectural decisions could you make to minimize impact?
Follow-up Questions
- What role does the Reflect metadata play in this process?
- How does Nest handle circular dependencies during injection?
- What changes when a provider is marked as request‑scoped?