feat(core): add generic type for transformed value in decorators factory

[quangtran88]

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?

Currently, the return type of Reflector.get(ReflectableDecorator) resolves incorrectly if the transform option is used with the Reflector.createDecorator call and the transformed value has a different type than the input.

Issue Number: #12264

What is the new behavior?

Add a second optional generic param on Reflector.createDecorator to describe the transformed value type as following:

const Roles = Reflector.createDecorator<string[], number>({
  key: 'roles',
  transform: (roles: string[]): string[] => roles.length, // Must return type number
});


const roles = this.reflector.get(Roles, context.getHandler()) // Will resolve as type number

Does this PR introduce a breaking change?

• Yes
• No

Other information

[coveralls]

Pull Request Test Coverage Report for Build 40597bd8-8e2d-44be-8dd8-1c7b6891dc78

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

---

Totals
Change from base Build 5bd17c50-f4ca-40e5-b4dd-2c0c2dd7c586:	0.04%
Covered Lines:	6428
Relevant Lines:	6945

---

💛 - Coveralls

[micalevisk]

I didn't tested

Can we supply that second type arg without any transform function? Because we shouldn't, right

[quangtran88]

I didn't tested

Can we supply that second type arg without any transform function? Because we shouldn't, right

Totally makes sense, I will make the transform option required if the second type arg is provided

[kamilmysliwiec]

lgtm 🚀

[BrianJacobo]

LGTM! 🚀