PokéClicker: an idle game whose numbers are written in TypeScript

An idle game with a contributor process attached

PokéClicker is described as the new and improved version of the popular idle and incremental PokéClicker, and the README summarises the game as a game about catching Pokémon, defeating gym leaders, and watching numbers get bigger. The live version is at pokeclicker.com, and the README says it is still in development, which is the first thing to weigh. This is not a finished product with a roadmap to a paid release. It is a community project with an active Discord and a documented set of rules for contributions, and that second half matters more than the game loop. The developer instructions spell out that the build script must succeed because pull requests that fail it will not be tested, and that balance pull requests are not accepted unless they come from a developer or Code Contributor role. The gates around content changes are as real as the gates around code changes.

TypeScript on top of Knockout, jQuery and Bootstrap

The stack is visible in package.json rather than in prose. The primary language of the repository is TypeScript, and the source lives in src/, with the scripts and modules linted separately by an eslint command that targets ./src/scripts and ./src/modules. The type definitions in devDependencies give the shape of the front end: @types/knockout for the binding layer, @types/jquery and @types/bootstrap with bootstrap-notify for the interface, @types/intro.js for the tutorial sequence, and @types/sortablejs for drag ordering. The build is Gulp driven, with gulpfile.babel.js and webpack.config.js at the root, and the run command sets NODE_ENV to development before invoking gulp. A vitest setup sits alongside it, with vitest.config.js and two setup files, so the test story is a unit test runner rather than an end to end suite. A .stylelintrc.json and a .eslintrc.js, plus an .editorconfig, mean the formatting rules are enforced by tooling rather than left to review comments.

Running the game from a clone in two commands

The build instructions are short and assume Git and Node are already on your PATH. You open a command line in the directory holding the README and install the dependencies locally, then start the game.

npm run clean

npm start

The clean script in package.json runs npm ci followed by the tl:init script, which runs git submodule update --init, so the translation content arrives as a Git submodule rather than as committed files. The start script runs gulp in development mode. The README adds a detail that saves a lot of confusion: changes to the source code automatically cause the browser to refresh, and you do not need to compile TypeScript yourself, because Gulp does it. The Cloud Shell route in the README is the same two ideas in a hosted terminal, with npm clean-install and npm start, and a Web Preview on port 3001 if you want to see the result without a local browser.

Deploying to GitHub Pages with two more scripts

The publishing path is documented as carefully as the local one. Before deploying, the README instructs you to check that the game compiles and starts up without errors. The first command builds the site, and it is worth reading what the script actually does, because it runs the whole test chain first.

npm run website

The website script runs tl:update, then npm test, then a production gulp website build, and the README says this populates the /docs folder. The test script itself is npm-run-all over three tasks with --continue-on-error: it compiles the scripts with gulp and runs vitest without coverage, then eslint, then stylelint. Once that finishes, the publish script runs the tests again and executes node publish.js, which by default pushes to the master branch, and that is the branch the live site is served from, as the version badges in the README make clear by pointing the develop branch at a dev version and the master branch at the live version. The default branch of the repository is develop.

Translations live in their own repository

One architectural choice deserves attention because it shapes how the project handles language. The tl:init and tl:update scripts drive a Git submodule, and the contributing rules say that pull requests adding new translatable content should link to a pull request in the separate translation repository, pokeclicker-translations, adding the new strings there, with the developer instructions on that repo carrying the detail. The consequence for a contributor is a two step change: the game code and the strings live in different repositories, and the strings are pulled in by a submodule update, with tl:update pulling from the remote rather than from a pinned commit. The README also lists tl:init and tl:update among the package.json scripts, and the repository root carries a .gitmodules file, which is the mechanism. Translations are therefore a first class part of the project rather than an afterthought, and a fork that ignores the submodule will run with whatever strings were last committed.

What a contributor is actually allowed to change

The developer instructions are unusually specific, and they narrow the contribution surface in ways that matter if you plan to work on the project. The build script has to pass, and pull requests that fail it will not be tested. Balance changes are refused from outside the developer and Code Contributor roles, which means a new game mechanic is a discussion with the maintainers rather than a patch. Translatable content is routed to the translation repository, and pull requests should be split into smaller ones so that review is easier and a rejected change costs less work. The tooling matches that discipline: eslint-fix and stylelint-fix scripts exist, so formatting problems are solved by running a command rather than by asking a reviewer to approve whitespace.

Version history and the state of the repository

The release tags give a clear picture. The current package.json version is 0.10.26, and the matching tag v0.10.26 was published on 2026-08-30, with v0.10.25 from 2025-08-13 and v0.10.24 from 2025-07-04 behind it. The version in package.json and the tag are kept in step, which is what lets the README badge read the live version from the master branch. The repository is not archived and the last push was on 2026-10-07, so the branch is still being worked on after the August tag. On licensing, the situation needs care: the repository listing gives the licence as unknown, while the package.json author field lists the ISC licence and names RedSparr0w as the author. If you plan to reuse code from the repository rather than just play the game, read the LICENSE file in the repository and settle that question yourself, and note that the game trades on Pokémon, which is Nintendo and Game Freak intellectual property rather than something this project licenses.

Editorial conclusion

Adopt PokéClicker as a reference for a browser idle game or as a project to contribute to, since its pipeline is a normal npm, Gulp and webpack setup with a published site you can play in a browser. Do not adopt it as a production service, because the project is a game that the README still marks as being in development, and its balance and content change under a contributor process that rejects outside balance pull requests. Before you fork it, check the Node version requirement in package.json, since devEngines asks for node ^24.0.0, and read the contributing rules in the README, because a pull request that fails the build script will not be tested.

Frequently asked questions

Official sources

1. Issues
2. pokeclicker/pokeclicker on GitHub
3. Project website
4. README
5. Releases