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

🤔

force-push it again @Gustrb

Hmmm, did it and the issue seem to continue.

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

oh, makes sense

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

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

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.

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.

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 😸

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.

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