feat(common): support empty @Inject() on constructor-based injection

[micalevisk]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

What is the current behavior?

Issue Number: closes #13426

What is the new behavior?

We can use @Inject() (ie., no token supplied) on constructor-based injections. It works just like property-based injection

Does this PR introduce a breaking change?

• Yes
• No

[coveralls]

Pull Request Test Coverage Report for Build d48faa69-328d-42fb-966e-6301bdeed1a3

Details

• 4 of 4 (100.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.003%) to 92.126%

---

Totals
Change from base Build 011c0093-57c9-44ca-8bbc-3c112693a9e8:	0.003%
Covered Lines:	6739
Relevant Lines:	7315

---

💛 - Coveralls

[benjGam]

Hi ! I'm not sure to understand, what this will produce as a result ? Will Nest take providers list as ref to auto-fill empty @Inject() calls to avoid errors ?

Edit: Just rephrasing to be clear.

[micalevisk]

nestjs will infer the provider token using parameter's metadata. Prior to this, such metadata is always ignored when using Inject on parameters because nestjs always use either the supplied token or the concrete class as the token

I don't know how to explain it more because I didn't follow if you're talking about the transpiled JS code or the runtime behavior.

Here's a video about the reflection on nestjs: https://youtu.be/jo-1EUxMmxc?si=ZvRQ8-6lac6Se3cS&t=779

[benjGam]

Sorry, yes i was talking about the runtime behavior.

[micalevisk]

regarding that, it will behave just like property-based injection. For them, the @Inject() is used due to introspection limitations. For constructor-based ones, we'll start supporting @Inject() for completeness sake only

[benjGam]

Ok, i understand the motivations, thanks for your reply !

[namgk]

any timeline for this to be merged?

[kamilmysliwiec]

lgtm