Should fix the UnhandledPromiseRejectionWarning #201 #225 #227 #229

[Schmoopiie]

I need some people to test this change and if everything goes well, I will land it on v1.2.2. I know that we will need polyfills for browser support and for backward compatibility for Node < 6. The main goal is to fix the deprecation warning when using Node 6, 7 and 8 (which is scheduled to be released on May 30, 2017).

[ThatLurker]

Any update on this?

[Yerrak]

Ran into a bunch of unhandled promise rejections today and it kind of pollutes my logs...
So, here is my attempt at getting this PR back on track.

Testing this PR in my simple use case of multiple times calling client.join() confirmed that it would work, assuming the caller consumes both, resolve and reject, like so:

client.join(channel).then((value) => {
    // [channelName]
}, (reason) => {
    // No response from Twitch.
});

What kind of confused me was that I was able to observe that the action (joining the channel in this case) was able to complete even though the promise was rejected due to losing the race against the delay.
The _promiseJoin was emitted shortly after the delay passed and processed nonetheless. This makes handling the rejection No response from Twitch kind of useless as it is not definitive.
Anyone has any insight into this behaviour (and possibly an already existing solution I missed)?

Because of the above, the approach of just catching the rejection as proposed here #201 also appeals to me - but as discussed over there, we would not be able to handle the promise result in the actual application that uses tmi.js.

I'm not quite familiar with compatibility considerations, but Promise.race() should work everywhere (except for IE of course).

(Reducing the promise delay to < 200 seems to be a nice and easy way to test this behaviour.)

[liquidvisual]

What's happening with this?