feat: version 5.0.0

[jmcdo29]

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 we cannot have multiple throttler contexts

Issue Numbers:

ref: #1369
ref: #1522
ref: #1443
ref: #1388
ref: #1492
ref: #1089
ref: #1221
ref: #894

What is the new behavior?

This is a bit of something that I've wanted to do for a while and inspired by this pr. With the new approach, we're now able to let users define scales at which they would like the throttling to work over, and let it work for any number of configurations, from a single 10 requests in 5 seconds to scales of months, or milliseconds

Does this PR introduce a breaking change?

• Yes
• No

It's worth noting there are quite a few breaking changes in this which will be reflected in the changelog as well, but better to have multiple mentions in my opinion

• ttl is now in milliseconds, not seconds, but there are time helper exposed to ease the migration to that
• the module options is now either an array or an object with a throttlers array property
• @Throttle() now takes in an object instead of two parameters, to allow for setting multiple throttle contexts at once in a more readable manner
• @ThrottleSkip() now takes in an object with string boolean to say which throttler should be skipped

Other information

docs pr

[jmcdo29]

@Ganesha2552 this PR is heavily inspired by your approach with my own take on it. Please feel free to review it and see what you think. I believe this has a bit more freedom about it on defining multiple scales to work with

[jmcdo29]

@benjlevesque if I could request you look over this too, as I believe I merged your changes in correctly and handled them as necessary, but want a second set of eyes on it

[weshuiz]

can i qucikly mention that the skip option could also be named forRoot/ forRootAsync as people will be already familiar with the phraze of it

[jmcdo29]

@weshuiz I'm not sure I understand what you mean here. ThrottlerModule has forRoot and forRootAsync

[weshuiz]

@jmcdo29 it was more of a name suggestion for the skip option
since it already exist, i gues never mind about this

[benjlevesque]

@jmcdo29 looks all right for my part👍

This change seems super useful, congrats!
Have you considered keeping a retro-compatible API for the @Throttle decorator, to keep upgrade simple and code tidy?

[jmcdo29]

@benjlevesque I've thought about it, but decided against it. Maintaining the backwards compatible @Throttler() API would be a burden, and while it shouldn't really be much of an issue, I figure just make it like a band-aid and rip it all off at once