feat(core/common): Add @Search decorator to the available HTTP route handlers

[Gustrb]

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: #10420

What is the new behavior?

This PR adds the new Search method decorator to be a valid handler to routes.
This change was rather simple, since both express and fastify already support this little akward and rather new http method

Does this PR introduce a breaking change?

• Yes
• No

Other information

[coveralls]

Pull Request Test Coverage Report for Build 7ebb1617-a886-4ce7-8c0b-7e619c5abc22

• 2 of 2 (100.0%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.4%) to 93.778%

---

Totals
Change from base Build c2dbdd8a-105c-4233-97cc-e76da419e49f:	0.4%
Covered Lines:	6149
Relevant Lines:	6557

---

💛 - Coveralls

[micalevisk]

can we move this to right below public all

[Gustrb]

sure thing!

[micalevisk]

🤔

force-push it again @Gustrb

[Gustrb]

Hmmm, did it and the issue seem to continue.

[micalevisk]

nvm that's due to this: #10545 (comment)

[Gustrb]

oh, makes sense

[Gustrb]

btw, should I do something to fix it or should I wait the other issue?

[micalevisk]

@Gustrb I guess you can apply the commit 9970ace here as well just to triggers the pipeline

[micalevisk]

I notice that this PR introduces a breaking change as the AbstractHttpAdapter is public and we're adding a new public mandatory method.

---

I feel that we could find a better way to add more route decorators... Express supports others routing methods that we won't bring to the core but we could have a way to let the consumer extending it if they want to.

An ideia: having a class with factory method that will use createMappingDecorator to create and register your route to a global storage.

[kamilmysliwiec]

I feel that we could find a better way to add more route decorators... Express supports others routing methods that we don't bring to the core but we could have a way to let the consumer extending it if they want to.

There's a way - you can inject the HTTP adapter and register the route manually, instead of using a dedicated decorator.

[micalevisk]

yeah... I'm thinking on how we could allow the usage of such new http method at controller's class as well.

@kamilmysliwiec from client POV, does having yet another decorator factory to create any http route sounds bad to you?

something like this:

const Search = HttpRoute('SEARCH')

class FooController {
   @HttpRoute('GET')('/')
   getHello() {}

   @Search()
   bar() {}
}

then all the native ones would be just an alias to that. Seems overkill & too flexbile but I don't see any other way.

I could try to implement that while still supporting @nestjs/swagger plugin somehow, if you like the idea 😸

[micalevisk]

I just notice that in the past Nest had the @RequestMapping({ method }) decorator factory. I don't know what were the reasons to remove that one but I guess we won't bring that abstraction to the core again.

[wenerme]

I don't find any reference, I think this maybe the QUERY method. https://www.ietf.org/archive/id/draft-ietf-httpbis-safe-method-w-body-02.html