Twurple: a TypeScript family of libraries for the whole Twitch API surface

One repository, five npm packages, one job each

Twurple describes itself as a set of libraries that aims to cover all existing Twitch APIs, and the repository is a monorepo. The root package.json declares workspaces of packages/* and is private, with the name twurple-workspace and version 0.0.0, so the published artifacts come from the individual package folders rather than from the root.

The split is the design. The readme names the packages and what each one does: @twurple/auth provides authentication functionality only, @twurple/api makes calls to the Helix API, @twurple/chat connects to and interacts with Twitch Chat, @twurple/eventsub-http listens to events using EventSub over HTTP and webhooks, and @twurple/eventsub-ws does the same over WebSockets.

That last pair is the interesting choice. EventSub is Twitch's event mechanism, and Twurple ships two transports for it, so you pick between webhooks and a persistent WebSocket depending on where your code runs. A bot on a server with a public address takes the webhook route; a bot on a laptop or behind a NAT takes the WebSocket route, and the same event types come through either way.

The top-level tree backs this up: a packages/ directory holds the individual libraries, docs/ holds the documentation, scripts/ holds build tooling, and there is a crowd.json file for translation, which is how the library ships in multiple languages. The shared TypeScript configuration lives in tsconfig.base.json with a tsconfig.json on top, and the repo also carries .eslintrc.js, .prettierrc.js and a .prettierignore, so linting and formatting are enforced at the repository level rather than per package.

Installing means picking a package, and the readme installs only auth

The installation section is short. To add Twurple to a project, the readme gives three equivalent commands depending on your package manager:

	npm i @twurple/auth
	# or
	yarn add @twurple/auth
	# or
	pnpm install @twurple/auth

Note what that installs. @twurple/auth is the authentication package, and the readme is explicit that the mentioned package only provides authentication functionality, with everything else in separate packages. If your application calls the Helix API, you need @twurple/api as well. If it joins chat, @twurple/chat. If it reacts to events, one of the two EventSub packages.

That is the main integration decision, and it is a good one to have to make explicitly. A project that only needs to read a user's channel metadata installs two packages, not five, and the unused surface area of a large SDK never enters your dependency tree.

The documentation site is the place to start, at twurple.js.org, and the readme says it includes a complete reference of all classes and interfaces, as well as changes and deprecations between major versions. That last part matters more than it sounds: this is a library with a major version number, and the deprecation notes are how you find out what a major bump breaks before you hit it.

Automatic token refresh is the feature that removes real work

The fourth bullet in the feature list is the one that decides whether a Twitch integration is pleasant to maintain: doing all of this without caring about the expiry of your access tokens, because the library can refresh them automatically.

Every Twitch integration has this problem. An app that calls the Helix API on behalf of a user needs an access token, that token has a lifetime, and refreshing it means either asking the user to authorise again or running a refresh token flow and storing the result. Bot authors end up writing that plumbing in every project, and they get it subtly wrong, and then a token expires at 3am.

Twurple keeps that inside @twurple/auth, so the rest of the code never holds a token expiry. That is the argument for the split as well: the authentication concerns live in one package with one job, and the API and chat packages consume it.

The library's origin story is in the readme's acknowledgements, which is worth knowing for a different reason. Discord.js is credited as the major inspiration for the structure of the libraries, and the phrasing notes that it was the library back then. Twurple is built by the same author who wrote discord.js, Daniel Fischer, who is also named as the author in the package metadata. So the API shape you may already know from a Discord bot is the same author's design, applied to Twitch.

What the library is for: bots, extensions and anything with a token

The topic list and the package set point to a specific audience. The repository topics include chat-bot, chatbot, twitch-extension, tmi, pubsub, eventsub, webhooks, api-client, twitch-api, twitch-chat and twitch-extension, which is a list of the things people build on top of Twitch.

The four use cases the readme names are concrete. Query the Helix API. Build a chat bot. React to custom redemptions, subscriptions and follows and more using EventSub. And do all of it without managing token expiry.

The chat story deserves a note. Twitch Chat is the IRC-based protocol the site itself uses for its chat, and the @twurple/chat package covers connecting to it and interacting with it. A separate package for it means a project that only sends chat messages does not pull in the Helix API client, and the two have genuinely different shapes: one is a REST client with typed responses, the other is a long-lived connection with a different event model.

The mention of PubSub in the repository description is the one loose end in the story, and the package list does not include a PubSub package. Twitch's PubSub channel is the older mechanism, and the EventSub packages are the newer ones. A project that still needs PubSub specifically would have to read the documentation site to see what is available, because the readme's package list does not answer it.

The build and test setup is a strict TypeScript monorepo

The root package.json is where the engineering setup is visible, and it is worth reading if you plan to contribute or vendor the source. The build is a single command, tsc --build, with a rebuild that cleans the compiled lib directories and the tsbuildinfo files under packages first, and a clean script that uses del-cli for the same paths. Tests run under vitest. Documentation is generated by documen.ts, the author's own documentation tool, at version 0.17.8.

The scripts encode the release discipline. preversion runs the build, the lint and the prettier check in sequence, so a version bump cannot happen with a broken build. prepublishOnly runs a full rebuild. Linting is eslint over the packages with the js and ts extensions, and prettier has separate check and fix scripts scoped to the packages directory. Husky wires a pre-commit hook through lint-staged, which runs prettier on js, ts, css, json and md files and eslint --fix on js and ts files.

The devDependency versions tell you the era of the codebase. TypeScript is pinned at around 5.9.3, vitest is at 4.0.13, and eslint is at 8.57.0 with the author's own eslint config at 6.3.0. The presence of tmi.js at 1.8.5 in the dev dependencies is a nod to the older Twitch chat library, which is presumably what the chat package is tested against.

The test command is vitest, run across the workspace, and the crowd.json file at the root is the translation config, so a change that touches a user-facing string also has a translation to keep in step.

Where Twurple is the wrong tool, and what to reach for instead

The clearest wrong-tool case is a project that needs one HTTP call to the Helix API with a token it already manages. Pulling in a package family, a token refresh implementation and a chat client to do a single GET is more machinery than the task deserves, and the readme's own structure makes the point that the packages are separately installable precisely so you can take only what you need.

The second case is a language question. These are TypeScript libraries built on a modern TypeScript toolchain, in a monorepo with a vitest suite. A Python or Go project integrating with Twitch has to look elsewhere, and nothing in the repository suggests bindings for other languages.

The third case is a hard dependency on the older PubSub path. The description mentions PubSub, and the topic list includes pubsub, but there is no PubSub package in the list. Anyone whose Twitch integration still depends on that channel should check the documentation before designing around Twurple, because the readme's package list is the only inventory available here and it does not cover it.

A fourth limit is the version coupling. The release history shows v8.2.0, v8.1.4 and v8.1.3 all published on 2026-09-25, which tells you the packages are released together and versioned together. That is convenient until you depend on two of them and one of them needs a major bump for a Twitch API change, at which point you upgrade both or pin around it. The documentation's deprecation notes between major versions exist for that reason, and reading them is part of adopting the library rather than an optional extra.

Editorial conclusion

Twurple is worth adopting for a TypeScript project that has to talk to Twitch, because the parts are separated sensibly, the Helix API, chat and EventSub each live in their own package, and the token refresh problem that every Twitch integration has to solve is handled inside @twurple/auth rather than in your code. It is the wrong choice for a project that only needs one authenticated HTTP call, and it is the wrong choice for anything that needs Twitch's PubSub channel, since the package list covers EventSub over HTTP and over WebSockets but no PubSub package. Before you commit, check the three things that decide the outcome: which package you actually need, since the install line in the readme is for @twurple/auth alone and the Helix API, chat and EventSub come from separate installs; that your TypeScript and Node versions fit, since the workspace compiles with TypeScript around 5.9 and the packages are built with tsc --build; and the release line, where v8.2.0 shipped on 2026-09-25 alongside v8.1.4 and v8.1.3 on the same day, which tells you the packages move in step with each other and are versioned together.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. twurple/twurple on GitHub