feat: array subscriptions

[NtTestAlert]

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

What is the new behavior?

• Decorator metadata is not overwritten
• Added new decorator @OnEvents

Does this PR introduce a breaking change?

• Yes
• No

Other information

[kamilmysliwiec]

Instead of introducing a new decorator, could we just modify the @OnEvent implementation to use the "extendArrayMetadata" under the hood?

[NtTestAlert]

The original decorator already accepts string|string[], so introducing string[]|string[][] would not be backwards compatible (can't tell if the string array is an array of events, or a single event with array representing the namespaces)

The PR changes allow OnEvent to be used multiple times on the same method properly, just the new decorator was added to allow conflicting signatures without breaking backwards compat (OnEvent calls OnEvents internally with a single element array).

[kamilmysliwiec]

I'm not saying that we should update the decorator signature, but just use the "extendArrayMetadata" function under the hood, as you did in the OnEvents decorator

[NtTestAlert]

Without OnEvents decorator it would still be impossible to attach events based on a dynamic array (say, based on a config class etc)

[kamilmysliwiec]

That's fine, we don't want to support such a feature in this package

[NtTestAlert]

Then I can remove this, but this would force users who need this use-case (incl me and commenters on the original issue[s]) to resort to monkey-patching decorator metadata with custom code instead of an easy to use decorator.

[kamilmysliwiec]

If you want to dynamically retrieve event names (and dynamically register handlers for them), you shouldn't use decorators in the first place

[NtTestAlert]

Example of dynamic parameters in decorators from nestjs docs https://docs.nestjs.com/fundamentals/custom-providers#class-providers-useclass
This will be impossible (say IS_DEV?['event1', 'event2']:['event1'])

---

Removing OnEvents from PR.

[kamilmysliwiec]

This is a different use case than what's stated in the docs

[NtTestAlert]

Removed

[sorsaffari]

looking forward to this being published 🚀

[NtTestAlert]

Rebased to newest master.
@kamilmysliwiec any update on this?

[Hatko]

A nice feature - we spent some time figuring out why passing an array doesn't work

[NtTestAlert]

I've made this fix in ~1h since first opening a github issue.
We are at 3 months, nearing 2 months of radio silence...

I hope everything is alright with @kamilmysliwiec - assuming so, since still active on gh.
Honestly I just want to see this fixed, so I can remove the workarounds and have cleaner code.

In the meantime, my fork can be used by adding

    "@nestjs/event-emitter": "github:NtTestAlert/event-emitter#1.3.1-multi",

to package.json should anyone want to use it as-is.
(added npm run build to prepare, so it can be installed directly as a github dependency)

the fork includes a "multi event" decorator, which is optional.
the other interface is and will remain fully compatible with vanilla.

Might publish npm package of the fork later, if longer term solution is required

[kamilmysliwiec]

LGTM