feat(common): add method options to @sse decorator

[TomerSteinberg]

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 @Sse decorator is hardcoded to use the GET method, which limits certain use cases where an EventSource polyfill on the client side uses a different HTTP method.

Issue Number: N/A

What is the new behavior?

The new behavior allows specifying which HTTP method the endpoint supports, while still defaulting to GET if none is provided

Does this PR introduce a breaking change?

• Yes
• No

Other information

This is my first time contributing to a repository, so please excuse any beginner mistakes I may have made.

[coveralls]

Pull Request Test Coverage Report for Build 1874048a-c11d-46df-aeda-b62a4468bf2a

Details

• 1 of 1 (100.0%) changed or added relevant line in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 88.927%

---

Totals
Change from base Build addc9f43-f31d-4145-9327-14d30a76e998:	0.0%
Covered Lines:	7324
Relevant Lines:	8236

---

💛 - Coveralls

[kamilmysliwiec]

AFAIR this is against the spec, isn't it?

[TomerSteinberg]

Thanks for the reply!
You're right, it does go against the spec. However, there are valid use cases where a two-request approach is less efficient. Polyfills like sse.js support this, and since the change is backward-compatible, I don’t see why Nest shouldn’t allow it for those who need it.