# Online-Go.com: a TypeScript web client and a real time protocol for playing Go

> The online-go.com repository holds the web client for the Online-Go.com server, built with Vite and TypeScript, with a real time goban protocol, OAuth2 application support and a Playwright end to end suite. It suits a developer who wants to build on the platform or contribute to a long lived open source game site, and it is one half of a client and server split.

**online-go/online-go.com** — Source code for the Online-Go.com web interface

- Repository: https://github.com/online-go/online-go.com
- Website: https://online-go.com/
- Stars: 1,575 · Forks: 413
- Language: TypeScript
- License: AGPL-3.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/online-go-online-go-com

## A client for a server that lives elsewhere

The repository contains the source code for the web client used by Online-Go.com, and the fact that the description says client rather than application is the first thing to understand.

Online-Go.com is a server with a large community of Go players, and this repository is the browser side of it. The division matters for anyone considering building on it, because the pieces you can extend are the interface and the protocol, not the game logic or the account system.

The stack is modern and specific. The language is TypeScript, the bundler is Vite, and the manifest names the package as `online-go.com` at version 5.1.0, marked private and of type module, with a node engine requirement of `npm >= 8.5.0`.

The scripts describe the shape of the work. `dev` and `vite` both run the dev server, `build` and `build-ci` run `vite build --emptyOutDir`. There is a separate `build:i18n` with `OGS_I18N_BUILD_MODE=true`, which tells you that internationalisation is a build time mode rather than a runtime toggle, and the `i18n/` directory at the top of the repository confirms it.

The quality tooling is extensive. `type-check` runs `tsc --skipLibCheck --noEmit`. `lint` runs eslint over `src/`. The prettier scripts use a `pprettier` wrapper rather than prettier directly, which is worth noting because it means the repository has a custom formatting entry point rather than running the standard binary.

And there is a dependency cruiser, `dependency-cruiser src`, with a `.dependency-cruiser.cjs` config at the top level. Dependency cruiser is a tool that enforces architectural rules on the import graph, which is how a large front end keeps a layer boundary from eroding. The presence of a config file for it suggests this repository has rules it wants checked in continuous integration rather than left to review.

There is also a bundle visualizer, `vite-bundle-visualizer -c vite.config.ts`, which plots what is in the output bundle. For a front end that has grown for years, that is a tool for answering the question of which dependency is costing the most bytes.

The licence is AGPL-3.0, and the last push was on 2026-10-19.

## The goban real time protocol, and OAuth2 for third parties

The developer resources section is short and it points at the two things a third party actually needs, the protocol and the credentials.

The real time API documentation is at the goban protocol page, and the name is the game's term. A goban is the board, and the protocol is how the client and the server exchange moves and state over a live connection. Online-Go.com is a real time service, so the protocol is the contract, and it is documented separately from the client source, which is the right split for anyone building a client that is not the official one.

The second resource is the OAuth2 Application Manager at the online-go.com/oauth2/applications path, with the note that you must be signed into an account on OGS to use it. So a third party application registers as an OAuth2 application and gets credentials, which is the standard shape for a platform that wants to hand out scoped access without sharing passwords.

There is a `JWT.md` file at the top of the repository, which is the documentation for the token format, and the presence of it alongside the OAuth2 manager tells you the authentication story is token based.

The rest of the resources are the ordinary ones. There is a developer documentation page at online-go.com/developer, a wiki at the repository for getting started and for how to use the website, and the contributing guide at CONTRIBUTING.md.

A fourth resource deserves a separate mention because it is unusual. The acknowledgements section thanks Uffizzi for providing ephemeral environments to preview pull requests. That means a contributor can open a pull request and see the change running, in a throwaway environment, before a maintainer has to install and start the project. For a project whose local setup involves a real server dependency, that removes most of the friction from contributing, and it is a small piece of infrastructure that does a lot of work.

## Local development, and the OGS_BACKEND switch

The Makefile is where the local development story is told, and it is more interesting than a wrapper around npm scripts.

The first thing it does is put the local node_modules on the path, `NODE_PATH:=node_modules:$(NODE_PATH)` and `PATH:=node_modules/.bin/:$(PATH)`, so that the tools in the project, eslint, tsc, prettier, the vite binary, are found without a global install. Then every target depends on `node_modules` and `.husky`, so the dependencies are installed and the git hooks are set up before anything runs.

The interesting targets are the ones that vary the backend. `local-dev` exports `OGS_BACKEND=LOCAL` and runs the dev server, so the client talks to a local server. `point-to-production` exports `OGS_BACKEND=PRODUCTION` and runs the same dev server, so your local frontend talks to the live site. `bot-dev` sets `OGS_BACKEND=LOCAL` with `OGS_PORT=8085`.

And then there are the stage targets, `stage1-dev` with `OGS_PORT=8001` and `stage2-dev` with `OGS_PORT=8002`, both against the local backend. That pair is a way to run two instances of the client against one local server, which is how you test a feature that involves two players, or a teacher running a demonstration with a second board.

The `update-worker` target is the one with a version number in it, `GOBAN_SOCKET_WORKER_VERSION=0.3`. It builds and then copies `dist/modules/GobanSocketWorkerScript.js` into a path outside the repository, `../ogs/services/_shared/GobanSocketWorker/`, with the filename carrying the version. So the socket worker is shared between this client and the server, and the version number is how the two sides agree on which copy is in use. Copying a build artefact into a sibling checkout is a manual step, which tells you the boundary between the two repositories is not fully automated.

There is a `Makefile.production` included at the end, and the `Dockerfile` is the small one, `FROM node:latest`, a yarn install, the source copied in, port 8080 exposed, and `npm run dev` as the command.

## The test suite, and the four levels of end to end coverage

The test story is the most elaborate part of the manifest, and it is worth mapping out because the names encode a lot of intent.

The unit tests are `jest`, with a `fresh-test` variant that clears first, and there is a `setup-jest.cjs` and a `teardown-jest.cjs` at the top of the repository. There is a `jest.config.cjs`.

The end to end tests are Playwright, and the scripts show several different modes. `test:e2e` runs `node scripts/run-playwright.js`. `test:e2e:parallel` runs a different script, `run-e2e-built.js`, with the `--build` flag, so the parallel run tests against a built bundle rather than a dev server. `test:e2e:built` runs the same script without the build flag.

The tagged grep flags are the interesting part. `test:e2e:util` sets `E2E_INCLUDE_UTILS=1` and greps for `@E2EUtils`. `test:e2e:quick` greps with `--grep-invert` for the pattern `@Smoke|@Slow|@Visual|@E2EUtils|@Manual`, so the quick run excludes everything tagged slow, visual, utility or manual. `test:e2e:ui` sets `PW_UI=true` for the Playwright UI mode, and `test:e2e:debug` runs with the debug flag.

So the suite is tagged by cost and by kind, and there is a way to run the fast subset. That is a mature arrangement, and it explains why the tags exist as literal strings in the script names rather than in a config file.

The CI entry point is `test:ci`, which runs `yarn test:e2e:docker:smoke && yarn test`, so the smoke suite runs against a container and then the unit tests run. The `e2e` target in the Makefile runs the parallel end to end suite with a moderator password passed through the environment and an optional `E2E_WORKERS` count, executed inside a running container with `docker exec`.

The `playwright.config.ts` and the `e2e-tests/` directory hold the configuration and the specs, and there is a `scripts/` directory with the runner scripts.

## Forums for features, the tracker for bugs, and a community small in one dimension

The README describes the shape of the project organisation, and it is more candid than most.

Online-Go.com has a very active community of Go players, however only a relatively small portion of the community actively develops the code base and regularly visits this github page and the issue tracker.

So there is a large user community and a small developer community, and the project copes with that by splitting where things go. The forums at forums.online-go.com should be used to discuss any proposed functional changes or any new notable features, allowing non developers to chime in with their thoughts and ideas. The GitHub issue tracker should be used to track all bugs, minor obvious enhancements, and accepted major enhancements.

And there is a rule about what a valid issue looks like. Any enhancements, and ideally bugs, posted need to be articulated in a way that it is obvious what needs to be done, and partial thoughts will be closed and should be moved back to the forums for further discussion.

That is a policy that protects the tracker from the most common failure of a volunteer project with a big user base, which is a tracker full of half-formed ideas that nobody has time to triage. The forum is where the community that does not write code participates, and the tracker is where the developers are expected to be able to act.

The contributing guide is the other half of the process, and there is a reward for people who link their GitHub account to their Online-Go.com user account, where you will receive top tier supporter status for three months after your most recent commit that gets merged. That is a small gesture with an interesting side effect. It links the two identities, so the person whose GitHub work is merged gets visible recognition in the game community, and it gives the maintainers a way to identify the contributors who are actually present.

The repository also carries the signs of a project that has adopted current tooling practices for agents. There is an `AGENTS.md`, a `CLAUDE.md`, a `.cursor/` directory and an `.openhands/` directory, alongside a `CODE_OF_CONDUCT.md`, a `SECURITY.md` and a `.husky/` directory for git hooks. The `submodules/` and `typings_manual/` directories suggest some dependencies are pulled in as submodules and that the type definitions are maintained by hand.

## Conclusion

Online-Go.com suits a developer who wants to write against the platform, whether that is a bot, a third party client or a custom interface, because the real time goban protocol and the OAuth2 application manager are documented and the client source is readable. Skip it if you are looking for the game server, since this repository is the web client and the server is a separate project, and note the AGPL-3.0 licence, which is the right thing for a hosted service and the wrong thing if you need to keep your own code closed. Before you build against it, read the protocol documentation and the JWT.md file, and plan for the long turnaround, since the project states that only a relatively small portion of the community actively develops the code base. The last push was on 2026-10-19.

## FAQ

### What does the online-go.com repository contain?

It contains the source code for the web client used by Online-Go.com, a TypeScript and Vite front end with internationalisation built as a separate mode, and it is licensed AGPL-3.0.

### How do I develop against Online-Go.com as a third party?

The developer resources point to the real time goban protocol documentation, the developer page at online-go.com/developer, the repository wiki, and the OAuth2 Application Manager at online-go.com/oauth2/applications, which requires being signed into an OGS account.

### How do I run the Online-Go.com client locally?

The Makefile targets set the backend through OGS_BACKEND, with local-dev using LOCAL, point-to-production using PRODUCTION, and stage1-dev and stage2-dev running two instances on ports 8001 and 8002 against the local backend.

### What testing does the Online-Go.com project use?

Jest for unit tests and Playwright for end to end tests, with tagged modes for a quick run that inverts the @Smoke, @Slow, @Visual, @E2EUtils and @Manual tags, a parallel mode against a built bundle, a UI mode and a debug mode.

### Where should I post a feature request for Online-Go.com?

The forums at forums.online-go.com are for proposed functional changes and notable features, so non developers can comment, while the GitHub issue tracker is for bugs, minor obvious enhancements and accepted major enhancements, articulated clearly enough to act on.

## Sources

- [Issues](https://github.com/online-go/online-go.com/issues)
- [License: AGPL-3.0](https://github.com/online-go/online-go.com/blob/main/LICENSE)
- [online-go/online-go.com on GitHub](https://github.com/online-go/online-go.com)
- [Project website](https://online-go.com/)
- [README](https://github.com/online-go/online-go.com/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/online-go-online-go-com