robotty / dank-twitch-irc Goto Github PK

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet.
We recommend using:

• CircleCI
• Travis CI
• Buildkite
• CodeShip
• Azure Pipelines
• TeamCity
• Buddy
• AppVeyor
  But Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

With this typescript syntax (stolen from the "net" definitions):

 /**
  * events.EventEmitter
  *   1. close
  *   2. connection
  *   3. error
  *   4. listening
  */

addListener(event: string, listener: (...args: any[]) => void): this;
addListener(event: "close", listener: () => void): this;
addListener(event: "connection", listener: (socket: Socket) => void): this;
addListener(event: "error", listener: (err: Error) => void): this;
addListener(event: "listening", listener: () => void): this;

emit(event: string | symbol, ...args: any[]): boolean;
emit(event: "close"): boolean;
emit(event: "connection", socket: Socket): boolean;
emit(event: "error", err: Error): boolean;
emit(event: "listening"): boolean;

on(event: string, listener: (...args: any[]) => void): this;
on(event: "close", listener: () => void): this;
on(event: "connection", listener: (socket: Socket) => void): this;
on(event: "error", listener: (err: Error) => void): this;
on(event: "listening", listener: () => void): this;

once(event: string, listener: (...args: any[]) => void): this;
once(event: "close", listener: () => void): this;
once(event: "connection", listener: (socket: Socket) => void): this;
once(event: "error", listener: (err: Error) => void): this;
once(event: "listening", listener: () => void): this;

prependListener(event: string, listener: (...args: any[]) => void): this;
prependListener(event: "close", listener: () => void): this;
prependListener(event: "connection", listener: (socket: Socket) => void): this;
prependListener(event: "error", listener: (err: Error) => void): this;
prependListener(event: "listening", listener: () => void): this;

prependOnceListener(event: string, listener: (...args: any[]) => void): this;
prependOnceListener(event: "close", listener: () => void): this;
prependOnceListener(event: "connection", listener: (socket: Socket) => void): this;
prependOnceListener(event: "error", listener: (err: Error) => void): this;
prependOnceListener(event: "listening", listener: () => void): this;

I have a client that connects to IRC and posts a single message before then disconnecting.

ChatClient#connect and ChatClient#jon both return promises, but ChatClient#close and ChatClient#destroy do not.

When I call ChatClient#close before then going to exit the script, it hangs for ages before eventually exiting (though sometimes it seems to hang forever -- 6hrs before GitHub Actions killed it).

What's going on? What is the proper way to close the connection and ensure its actually closed, in a sensible time period?

in dist/index.d.ts, typescript replaces /// <reference path="../types/debug-logger/index.d.ts" /> with /// <reference types="debug-logger" /> which just doesnt work with other people including those definition files.

For now I've been rewriting the build files manually before release but it should be FIXED on typescript's end or there should be an automatic replacement at build stage

I'm trying to run a twitch IRC client on a server, and I can connect, join, and send messages, I just cannot receive messages. It works fine on my computer, but not on the server. Is there a standard way that I'm supposed to go about this? Could server proxying etc. affect this?

Related to types from ts-toolbelt and duplexify missing. O_o I'm not sure how to fix that.

https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html#dependencies

Twitch recently fixed their rate limits to actually match the documented limits.

It seems twitch has, at some point, changed the labels for some of their USERNOTICE eventParams such that they're inaccurate right now in the readme. I'm not sure what the correct solution for this is long term, since twitch is willing to just switch everything up willy nilly, but here's a few I noticed:

subgift:

• recipientUsername is actually recipientUserName
• There's a giftMonths param, not sure what this does.
• There's also an originID param, not sure what this does.

raid:

• displayName -> displayname
• viewerCount -> viewercount, and it comes in as a string.
• There's a profileimageurl param

Chatrooms don't have some properties:

https://dev.twitch.tv/docs/irc/chat-rooms/#roomstate-twitch-chat-rooms

Which currently causes hiccups in the roomstate tracker

When running dank-twitch-irc in a browser that has no ES2018 support (like Firefox) it will crash because of some regexp issue.

It would be nice if dank-twitch-irc supported most major browsers and recent versions of them.

Similar to #25, parsing string tags in parseTwitchMessage (specifically when parsing ClearchatMessage) is done by locally catching and throwing errors. This has a signifcant impact on performance, especially when multiple are being encountered at the same time.

In the Client Options documentation and specifically for the requestMembershipCapability option it mentions the following:

  // If you need live update of who's joining and leaving chat,
  // poll the tmi.twitch.tv chatters endpoint instead since it
  // is also more reliable

I've searched high and low in the Twitch documentation for a "chatters" endpoint. Could you please share what you mean by that? Is it an API endpoint or a hidden IRC command?

I'm trying to get close to real-time capture of JOIN/PART events but it seems most libraries are delayed in receiving these events by about three minutes. Is it possible to capture these faster?

Thanks in advance for any advice/guidance you have to offer 🙂👍

Very, very rarely I've found that usernames sometimes have a space appended to the end, and it tends to happen on the same user multiple times. Here are the few that I've found in Destiny's chat, out of millions that have been sent in the timeframe:

When building tsc fails with these errorrs.

$ tsc
node_modules/dank-twitch-irc/dist/mixins/roomstate-tracker.d.ts:11:47 - error TS2507: Type 'typeof EventEmitter' is not a constructor function type.

11 export declare class RoomStateTracker extends EventEmitter<RoomStateTrackerEvents> implements ClientMixin {
                                                 ~~~~~~~~~~~~

node_modules/dank-twitch-irc/dist/mixins/userstate-tracker.d.ts:13:47 - error TS2507: Type 'typeof EventEmitter' is not a constructor function type.

13 export declare class UserStateTracker extends EventEmitter<UserStateTrackerEvents> implements ClientMixin {

Refresh/get the token BEFORE attempting connection

Maybe in the same style as the connection rate limiter? (Mixin?)

There isn't a function to change the username color. So I wanted to see if anyone knows the IRC sendRaw to do this?

Hello, I keep getting the same error every time I Join or Part a channel.
Example when joining a_twitch_user:

JoinError: Failed to join channel a_twitch_user: Timed out after waiting for response for 2000 milliseconds

I get the same message, but a PartError when parting any channel.

The thing is, that I'm still successfully joining and parting the channels anyway. I am getting chat messages after I join and I'm not after I part. Yet the errors suggests that I shouldn't.

My current workaround is to try/catch these errors and just silently discarding them, but why am I getting them in the first place? Is there something I'm doing wrong? I tried to search for existing issues with the same problem but couldn't find anything.

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet.
We recommend using:

• CircleCI
• Travis CI
• Buildkite
• CodeShip
• Azure Pipelines
• TeamCity
• Buddy
• AppVeyor
  But Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

On USERSTATE or ROOMSTATE

If the bot gets banned in a channel, a PART message is received and the bot gets forcefully PARTed from that channel.
However, the ChatClient object roomStateTracker does not get updated and still shows the channel that the bot got banned in, so if I try to rejoin the channel nothing happens unless I manually use client.part() (which will throw an error) and join again.

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet.
We recommend using:

• CircleCI
• Travis CI
• Buildkite
• CodeShip
• Azure Pipelines
• TeamCity
• Buddy
• AppVeyor
  But Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

helix API returns them as strings so it feels like a good practice to treat them as strings too.

Typing out 👉 <3 in chat gives the following msg.emotes[] value(s):

TwitchEmote { id: '445', startIndex: 2, endIndex: 4, code: ' <' }

Typing out 👉 <3 👉 <3 👉 <3 in chat gives the following msg.emotes[] value(s):

TwitchEmote { id: '445', startIndex: 2, endIndex: 4, code: ' <' }
TwitchEmote { id: '445', startIndex: 7, endIndex: 9, code: '� ' }
TwitchEmote { id: '445', startIndex: 12, endIndex: 14, code: '�' }

The startIndex& endIndex is also wrong because emote counts as more characters than one.

I'm pushing a pull request that fixes msg.emotes[].

In a case where you queue up a bunch of messages in one channel, and while those messages are still sending, you try sending another message in a second channel, the second channel's message will only send once the first messages have all finished sending - and if that isn't before 2 seconds, the lib will throw a Timed out after waiting for response for 2000 milliseconds error on the second channel's message.

This seems to be due to the fact that the timeout "counter" begins immediately upon dispatch of the message, and not after waiting for the previous commands to finish.

Create new connections when lots of messages need to be sent

https://github.com/robotty/dank-twitch-irc/blob/master/lib/mixins/ignore-promise-rejections.ts

setColor should probably be there.

tsconfig.json, under compilerOptions:

"stripInternal": true,

And add comments like these:

/**
 * @internal
 */

dank-twitch-irc randomly fails when trying to send a message with this error:
SayError: Failed to say [#channel]: message: Timed out after waiting for response for 2000 milliseconds

Feature request

Invocation of the <ChatClient>.say() method when "#" is included at the beginning of the channel name currently results in a ValidationError: Channel name "#channel" is invalid/malformed error.

As someone porting over from another IRC library which allows such behavior, my code is written in such a way so that messages must be able to send with the preceding "#" before the channel name. Perhaps it would be worthwhile to implement such functionality as well?

Would be a really nice feature instead of rate-limiting commands sent by the client it would be on a per-connection basis.

Maybe make prom-client an optional dependency?

When parsing message tags, methods that parse specific tag types rely on locally caught errors to determine whether or not given tags are present in the message.

This leads to performance drops as constructing an Error object (in this case, ParseError or MissingTagError), throwing and then locally catching it is not trivial in the backend - compared to, for instance, returning a null value.

Attached is a CPU profilling snippet preview, where this behaviour is shown. In a single message event, almost 60-70% of processing is done in local error catching.

Would be a nice feature to either return the msg itself or the notice id of a successful ban. Very useful to know whether it created a new ban or if the ban already existed, ie returning ban_success or already_banned instead of returning undefined on the ban operation. Same for the timeout operation.

Example that failed in the message parser:

@badge-info=subscriber/3;badges=subscriber/3;color=#0000FF;display-name=Linkoping;emotes=25:40-44;flags=17-26:S.6;id=744f9c58-b180-4f46-bd9e-b515b5ef75c1;mod=0;room-id=188442366;subscriber=1;tmi-sent-ts=1566335866017;turbo=0;user-id=91673457;user-type= :[email protected] PRIVMSG #queenqarro :Då kan du begära skadestånd och förtal Kappa

emotes=25:40-44 is out of bounds and makes the message parser fail