Is there an existing issue that is already proposing this?
Is your feature request related to a problem? Please describe it
When Nest cannot resolve a dependency, the UNKNOWN_DEPENDENCIES_MESSAGE
may produce slightly awkward or ambiguous phrasing in certain edge cases.
For example, when the injection token name is undefined, the message may render:
"the argument dependency at index [0]"
Additionally, string and symbol injection tokens are not always rendered
as clearly or consistently as they could be.
Describe the solution you'd like
Refine UNKNOWN_DEPENDENCIES_MESSAGE formatting to:
- Display the injection token name only when it is defined
- Properly render string tokens (e.g. "DATABASE_URL")
- Properly render symbol tokens (e.g. Symbol(MY_TOKEN))
- Replace "context" with "module" for clarity, since users typically
reason about their application structure in terms of modules
This would not introduce any API or behavioral changes.
It is strictly a developer-experience wording refinement.
Teachability, documentation, adoption, migration strategy
No migration or documentation changes would be required.
This proposal only adjusts internal error message formatting.
It does not affect public APIs or runtime behavior.
What is the motivation / use case for changing the behavior?
Clear dependency resolution errors are critical for debugging,
especially in larger modular applications.
Improving token display and removing ambiguous fallback wording
can make troubleshooting faster and reduce confusion,
while keeping the existing error structure intact.
Before opening a PR, I wanted to confirm maintainers are open
to small wording refinements in this area.
Is there an existing issue that is already proposing this?
Is your feature request related to a problem? Please describe it
When Nest cannot resolve a dependency, the UNKNOWN_DEPENDENCIES_MESSAGE
may produce slightly awkward or ambiguous phrasing in certain edge cases.
For example, when the injection token name is undefined, the message may render:
"the argument dependency at index [0]"
Additionally, string and symbol injection tokens are not always rendered
as clearly or consistently as they could be.
Describe the solution you'd like
Refine UNKNOWN_DEPENDENCIES_MESSAGE formatting to:
reason about their application structure in terms of modules
This would not introduce any API or behavioral changes.
It is strictly a developer-experience wording refinement.
Teachability, documentation, adoption, migration strategy
No migration or documentation changes would be required.
This proposal only adjusts internal error message formatting.
It does not affect public APIs or runtime behavior.
What is the motivation / use case for changing the behavior?
Clear dependency resolution errors are critical for debugging,
especially in larger modular applications.
Improving token display and removing ambiguous fallback wording
can make troubleshooting faster and reduce confusion,
while keeping the existing error structure intact.
Before opening a PR, I wanted to confirm maintainers are open
to small wording refinements in this area.