The @Optional() decorator marks a constructor dependency as optional. If the provider is not registered in the DI container, NestJS injects undefined instead of throwing an error. Useful when building libraries or optional integrations where a provider may or may not be configured by the consumer.

Using @Optional()

When to use @Optional():

1
Building reusable library modules where consumers may not configure all providers.
2
Feature flags — optionally inject a service only when a feature module is loaded.
3
Fallback behavior — use a default implementation when the provider is absent.
4
Always use TypeScript optional typing (?) alongside @Optional() for type safety.

Difficulty: 5/10

Topics: dependency injection, parameter decorators, module design

Scenario Questions

0-2 years experience

1
You have a service that sometimes receives a logger via constructor injection, but you want the service to work even if the logger isn’t provided. How would you use @Optional() in the constructor?
2
If you forget to add @Optional() to a parameter that might be undefined, what runtime error will Nest throw when the provider isn’t registered?
3
What happens if you mark a parameter with @Optional() but also give it a default value in the constructor signature?

2-5 years experience

1
We conditionally register a caching provider based on an env variable. After removing the provider, a controller that injects it started throwing errors. Walk me through how @Optional() could prevent the crash and what changes you’d make in the controller.
2
During debugging you notice a service injected with @Optional() is always undefined even though the provider is registered in another module. What could cause this and how would you fix it?
3
Explain the trade‑offs of using @Optional() versus manually checking for a provider’s existence in a factory provider.

5-8 years experience

1
Design a reusable NestJS library that offers optional integrations (e.g., a metrics collector). How would you structure the module and use @Optional() so consuming apps can opt‑in without breaking if they don’t install the integration?
2
Many microservices share a core module that optionally injects a feature‑flag service. Discuss potential pitfalls of overusing @Optional() in that shared module and how you’d mitigate performance or maintainability concerns.
3
If you need to lazily load an optional provider only when a certain request header is present, how would you combine @Optional() with dynamic module loading to keep the DI container efficient?

8+ years experience

1
Your organization is migrating a monolith to microservices. Several services currently rely on @Optional() to guard against missing legacy providers. What architectural guidelines would you set to decide when @Optional() is appropriate versus refactoring to explicit contracts, and how would you manage the risk of silent failures across teams?
2
In a large codebase you discover widespread use of @Optional() leading to hidden null‑pointer bugs. Propose a strategy for auditing and refactoring these usages, including tooling, code‑review policies, and documentation updates.

Follow-up Questions

❓Can you sketch the constructor signature showing @Optional() with a default value?
❓What would happen if the same token is later registered in a dynamic module?
❓How does using @Optional() influence unit‑test mocks?