Maintainers

[marcandrews]

Is this project still being actively developed? Is there anything I can do help with maintenance?

[AlcaDesign]

As much as I'd like to say that it can be active, @Schmoopiie is apparently busy and/or away for now and I lack the understanding of his vision of how to properly maintain the library. (As well as I can't update tmi.js on NPM) I think the next best thing would be to reinvent the wheel and make a new codebase. I've rewritten a basic Twitch IRC library a few times now trying to keep the code simple and follow simplistic and more straightforward design. Unfortunately I suffer from a painful disease called laziness and boredom and rarely finish things once the task seems daunting. But that's not for a lack of trying. If I get the willpower, I'd like to finalize something and put it up on the team Github (tmijs) and publish a new module to NPM. I've heard a lot of feedback and worked with many people over the years so I understand where the faults are of the library. Especially there's been a lot with not giving all available data, function argument order being hard to understand on initial development issues, and misunderstanding necessary code logic that results in chat loops.

Requirements for a new version:

• Minimal, fast processing
• Minimized redundancy
• Minimized redundancy
• Always emit objects instead multiple arguments
• Emit all available data, including a "raw" event
• Remove "#" from channel names when used externally
• Minimized redundancy
• Optional but default intelligent message queue

And there's probably more that has slipped my mind.

[marcandrews]

I appreciate the response.

• Not having access to NPM is only slightly concerning, as people can still install it directly from GitHub.
• I don't think we need to re-invent the wheel entirely, especially given the state of flux of the current Twitch API, but I wouldn't mind contributing to your Twitch IRC library either.
• Laziness and boredom are some of the best qualities a software developer can have.

I really think this can be maintained by the community, but we are lacking a few key components:

• [x] continuous integration (TravisCI)
• [ ] strong linting definitions (ESLint)
• [ ] targets for minimum code test coverage (Coveralls)
• [ ] auto-generated documentation
• [ ] continuous delivery

Once these are in place, we can bring the test coverage up, and then merging PRs should be trivial. At this point, we can start working on your requirements for a new version.

What do you think?

[Schmoopiie]

I'm so sorry for the lack of communication and I know I haven't updated the module for a long time now. I have been very busy, had serious health issues and had a lot of life changing events in the past few months. At this time, I don't know if I will ever be able to maintain the module again (I don't even have time to update the forums -_-'), so I might give away ownership of the module. I need a few days to think about it.. tmi.js is like my baby 😸 If I do so, the ownership will go to @AlcaDesign as I trust him a lot and I know he is going to do a great job. I will keep you guys updated in a week or so.

@AlcaDesign I will DM you next week on Twitter before taking any action

[marcandrews]

Thanks @Schmoopiie. Sorry to hear about that and I hope everything works out.

You and the team have built something great, and the Twitch community is massive so I am hoping that with a solid CI/CD strategy, maintaining this should be easier. tmi.js is your baby, so do you have to transfer ownership, or can you just make @AlcaDesign an admin?

I have a little side project that is dependent on tmi.js, so I'd rather contribute here than to my own fork ... and there must be hundreds of projects that rely on tmi.js, so there are definitely quality contributors out there.

As long as there is someone able to review/merge PRs with access to external services (Travis, etc.) I will work on the CI/CD.

[embiem]

I really hope things get better for you @Schmoopiie! Your baby certainly is the best interface to Twitch's API & chat out there.

As I'm also using this library in a hobby project, I'd love to contribute more along the way and help make tmi.js better. So, @AlcaDesign if you need any help, then I'd be happy to take a few TODOs off your back.

Cheers!

[mattnotmitt]

I definitely think this project can continue a healthy life with all of these potential contributors :)

[marcandrews]

Any updates?

[Schmoopiie]

Had a week to thing about it and I decided to transfer ownership to @AlcaDesign. I know the project is in good hands now 😄

Thank you <3

[AlcaDesign]

@marcandrews -- I am now an overlord of all that is tmi.js! MWA HA HA HA

[marcandrews]

Nice! So what's the next step?

[stachu540]

Don't over-Kapped dude, cause we will merge tons of Kappa's to this repository.

So we will wait for some updates.

[marcandrews]

I will not wait for updates. If I want an update, I'll make a PR.

[mccxiv]

Thank you @Schmoopiie for all your hard work and cheers to @AlcaDesign

"Working code is a rare and beautiful thing" is a quote that has stuck with me for many years, so I would issue a word of caution in regards to ambitious rewrites. Or at least a "spec first, code later" approach so that you can receive feedback, help, and motivation along the way

[embiem]

I agree, definitely thank you @Schmoopiie & @AlcaDesign.

For the future, I'd like to see a refactoring / "modernizing" branch. This should not change any of the features or re-write the whole library, but attempt to get ready for modern build pipelines (e.g. like #239 or #237) and use ES6 as well as a more consistent code style throughout the code base.

This would already complete one of @AlcaDesign's ToDos mentioned above: Minimized redundancy.

After finishing the refactor, additional features and changes like the mentioned "Emit all available data, including a "raw" event" would be implemented.

In my mind, this would be the next steps. What do you think?

[AlcaDesign]

I still would like to have an alternative, from-the-ground-up version of tmi.js made with vastly reduced code released as a beta in the coming month(s). In fact, the last month for me has been writing it when I get time. It's not even kind of close to being done but the main functionality is there. I'm currently just supporting "latest" Node, as that's what I use, in es6-style but with transpilation and/or polyfill it's a non-issue. I intend to write it as almost a plug-and-play replacement but with some real differences. It'll look and work basically the same, but it'll improve on headache that I've seen.

All tag objects will be camelCased and channel names with the # removed. Both will always be included if they're available. Events will always be called with an object for the arguments. Here's what the message event would look like with object deconstruction:

client.on('message', ({ channel, tags, message, fromSelf }) => {

And here's the current target of everything that comes with the object:

{
    // Notice no #:
    channel: 'channelname',
    tags: {
        badges: { // Or null
            subscriber: '0',
            bits: '5000'
        },
        color: '#FF0000' // Or null
        // Notice the camelCase key:
        displayName: 'DisplayNameHere',
        emotes: {
            // Emote ID
            1: [
                // 0-based indices with 1 added to the second, works like `Array.prototype.slice`.
                // Using an array instead of a string:
                [ 9, 11 ]
                // -> emotes[id].forEach(indices => console.log(message.slice(...indices)));
                // <- ':)'
            ]
        },
        id: '712ac163-f232-4d2a-bc41-10c74d26de3c',
        mod: false,
        // name = displayName || username; // Useful for reply messages
        name: 'DisplayNameHere',
        // Notice issue with camelCase, Id or ID? It's at least consistent.
        roomId: '987654321',
        // Potentially parsed by Date, not sure yet. Also notice: Ts or TS?
        sentTs: 1503480408818,
        turbo: true,
        userId: '123456789',
        username: 'usernamehere',
        userType: null // Or a string
    },
    message: `'hey dude :)'`,
    rawData: {
        // The original input IRC string
        raw: '...',
        // Original tags
        tags: {},
        // Special things happen here, definitely worth including
        prefix: {
            // The original IRC prefix string
            raw: '',
            isServer: false,
            nick: 'username',
            user: 'username',
            host: 'username.tmi.twitch.tv'
        },
        command: 'PRIVMSG',
        params: [ '#channel', 'hey dude :)' ],
        channel: 'channelname',
        // Date instance, which will be used for all lines of IRC that is part of the same socket message.
        receivedTimestamp: new Date()
    }
}

As it stands, tmi.js currently works very well. I personally use it in my very large chat bot codebase and it's been going strong for well over a year. I don't know if Schmoopiie has experience of using tmi.js in that manner, but I feel that I have a good idea of how bots should work, how people actually use it, and what a new version could do to improve many aspects. There's also its usage in a browser for things like overlays as a read out or to control animation and alerts, personal websites when the stream's live, and plenty more that I've extensively experimented with.

Try this CodePen pen where I've written an almost fully explored multi-chat with support for all badges, emotes, BTTV emotes, emoji, timeout/bans/clears, temporary connectivity messages/alerts, filters for weird characters. (Check the console after a little while to see what it catches) It's missing Clips, Cheering, spam "protection".

I've seen and even been messaged by many first-time programmers using tmi.js. Once they're past using Node, NPM, command prompts/terminals, and editors, they can really quickly make a small bot that connects to their channel and can reply to their input. There's a real fascination with bots on Twitch and this library enables people to do it so simply.

I would really like to hear thoughts on the idea of a new tmi.js.

[g33kidd]

I'm all for a new tmi.js! I've only started using tmi.js today, but since using it I've basically thought about what I would do and you nailed it with all the points you've made so far. Heck, I would be so down to help with something like this.

There are a few things I would like to have added in this new tmi.js, like some helper methods for kraken endpoints. I noticed not a lot of REST methods are supported like getting the games, etc... Would be nice to have some convenience methods to make it a bit easier. 😄 But I'd have to get some more usage out of the current tmi.js in order to really tell what's needed (for me personally, maybe others too).

So far, I love it!

[AlcaDesign]

@g33kidd Covering the API is not the intention of this library, but a separate one could do the trick. Assuming you mean more than just what's already available. I'm definitely interested in having a public module for this as my bot already has an extensive private module covering most of the actually useful APIs.

[g33kidd]

I just realized what TMI meant, and that totally makes sense; I guess it's really no problem to use a separate package for just the Twitch API. Do you have any suggestion for a package that does support the APIs? This is the one I was looking at https://github.com/thedist/Twitch_API_v5

Actually, I would love to have something similar to what you have here (https://github.com/AlcaDesign/Alcabot-Obfuscated/blob/master/lib/twitch-api.js) Kappa

[johnRivs]

First off, congratulations to @AlcaDesign and a big thank you to both him and @Schmoopiie You guys and the rest of contributors have done such a good job with this package.

I see some of the focal points for a "new" tmi.js would be things that have to do with ease of development and consistency on its API in order to streamline the process of contributing and maintaining the package. I like that stuff, but I'd like to add something to the conversation: connection strategy.

Currently, I find myself trying to understand how rate limits work. It simply doesn't make sense to me how popular bots don't get locked out. 100 messages across all channels in a 30s window (assuming the bot is modded) seems way too easy to hit. So for the next interation of tmi.js, I'd like to see some out-of-the-box solution for some sort of cluster mode (or something) to distribute the load across multiple connections or IPs or whatever's neccesary. I think we need 100% transparency on that, how the bot connects to chats and other inner workings.

I also agree with @AlcaDesign about the API. Let's leave it outside tmi.js.

[erezefrat]

Hey @AlcaDesign, glad to read you're working on a new version of tmi.js! I've started working recently with tmi.js, and have encountered some issues (which have been reported by other people, it seems). Hopefully they'll be resolved in the new version.

Any ETA on the new version?

[loligans]

It would be really cool to see a TypeScript version of tmi.js! Or just a declaration file to make it easier to know what exactly the object I may deal with contains.

[marcandrews]

Did this repo die again?

[marcandrews]

To help development, I have created a new clone of tmi.js called TwitchJS (Github, NPM). I have already merged in 8 of 10 open PRs and published the module on NPM.

Anyone who submits a PR that meets all the contribution guidelines (basically passes tests without much involvement from existing contributors) will receive merge rights. As such, I have already sent out collaborator invites to those authors whose PRs were merged.

Please feel free to make issues and PRs for TwitchJS and hopefully we can keep this code alive.

[spesvictus-zz]

Yeah We need more community focus library over centralized ownership. It is how Open Source Software works. tmi.js needs to get ready for final completion of Helix api and it should be done with most parts already with fully ES6 compliant library.