# BaekjoonHub pushes judge site solutions into a GitHub repository

> BaekjoonHub is a Chrome extension whose one job is to take a solution you submit to a Korean online judge and put it into a GitHub repository, so the record of what you solved ends up in version control instead of in a browser tab. It supports four judges, ships with a popup page and a welcome page, and its release history is a steady stream of patch versions.

**BaekjoonHub/BaekjoonHub** — 백준 자동 푸시 익스텐션(Auto Git Push for BOJ)

- Repository: https://github.com/BaekjoonHub/BaekjoonHub
- Stars: 974 · Forks: 142
- Language: JavaScript
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/baekjoonhub-baekjoonhub

## The gap between solving and keeping

The tagline in the repository is short and describes the entire product: automatically sync your code to GitHub. The problem it solves is specific rather than technical. Online judges are places where you write a solution, submit it, and get a verdict, and the code itself often stays in a text box on the page, or in a local file named after the problem number that you forget about. A portfolio built on those submissions is therefore a manual archive, and it is a portfolio that is worth keeping, because a year of solved problems is a piece of evidence about how you work. The extension moves that copy step out of the way, so the repository updates itself as you solve. The target user is a student preparing for programming competitions or a working engineer keeping a public record, and the Korean judge sites are where the practice happens.

## Four judges, one repository

The package description names the supported sites: it is a Chrome extension that auto-pushes BOJ/Programmers/SWEA/goorm submissions to GitHub. Baekjoon is the largest of them and the one the project is named after, Programmers is the other Korean judge with a large problem set, SWEA is the Korean software education exam. The repository topics agree with that list, carrying baekjoon, groom, programmers and swea, and no others, which tells you the extension is not a general purpose web scraper with a Korean accent. It is a set of per-site integrations. That matters for how you should read the rest of the project, because the hard part of this kind of extension is not the GitHub side, which is a documented API, it is the per-site details, since every judge has its own problem page layout, its own code language selector and its own idea of what identifies a problem.

## The shape of the extension

The top level of the repository is a Chrome extension laid out in the conventional way, and the file names tell you more than the README does. There is a manifest.json, which is where the permissions and the background service worker are declared. There is a popup.html with a popup.js, which is the little panel you get when you click the toolbar icon, and a welcome.html with a welcome.js, which is the first-run page that usually asks for the settings the extension needs. There is a css/ directory for the styles of those pages, a library/ directory for the code, an assets/ folder holding the thumbnail image used in the store listing, a rules.json file at the top level, and separate scripts/ and tests/ directories. The presence of rules.json is the interesting one, because a rules file at that level is where per-site configuration would live, which matches the model of a project that supports four judges.

## Tests run on the Node test runner

The package file is small and gives the test command away:

```json
{
  "name": "baekjoonhub",
  "version": "1.4.21",
  "description": "Chrome extension that auto-pushes BOJ/Programmers/SWEA/goorm submissions to GitHub",
  "private": true,
  "scripts": {
    "test": "node --test"
  },
  "license": "MIT"
}
```

The test script is node --test, which is the test runner built into Node itself rather than a framework, so the project has no test dependency to install and no configuration file to inherit. That is a deliberate-looking choice for a small extension, since the toolchain around it is equally thin. There is an.eslintrc for linting, a.prettierrc for formatting, and an.all-contributorsrc which is the configuration file for the contributors table. The tests directory exists as a top level entry, so the runner is pointed at something. There is also an.ignore_release file, which is the kind of marker a project uses to keep a release automation workflow from triggering on a particular commit, for example a version bump.

## A community with named responsibilities

The README spends most of its length on a contributors table, and the table is more informative than it looks because each entry is tagged with a role. There are entries for maintenance, for talks, for documentation, for answering questions, for code, for bug reports and for business development, and the names are attached to those roles with links to the relevant issues or commits. So the project is not a single person pushing to a personal account, it has people whose job is to keep the extension working against changing judge sites, and people whose job is to keep the documentation current. For a user, that is the difference between an extension that keeps working and one that quietly stops, because a judge site redesign breaks the page parsing, and someone has to notice. The releases reflect that attention, with a stream of patch versions rather than occasional jumps.

## What the README does not tell you

The honest limitation is that this README is a landing page. It has a title, a thumbnail, badges for the licence and the Chrome Web Store listing, and the contributors table, and it stops there. There is no installation section, no configuration walkthrough and no description of what happens to your code after it is submitted, so the practical questions, how the GitHub credentials are stored, what the target directory layout looks like, whether the commit message can be customised and what the rules.json file actually controls, are not answered by the repository. The Chrome Web Store listing is linked from the badges, and that is where the user facing documentation lives. The rest of the repository is where the implementation is, in the library, scripts and tests directories, and the extension manifest is the place to start if you want to know what permissions it asks for. The licence is MIT, the extension is published on the Chrome Web Store, and the release history shows v1.4.21 on 2026-09-24, v1.4.20 on 2026-09-23 and v1.4.19 on 2026-08-08, with the last push on 2026-09-24.

## Conclusion

BaekjoonHub fits a student or engineer who solves problems on Korean judge sites and wants a public record of that work in a repository rather than scattered across accounts, since the extension removes the copy and paste step between submitting a solution and committing it. It does not fit a developer who wants a general purpose scraper for arbitrary sites, because the rules are per judge and are not described outside the extension itself. It does not fit a team with a strict policy on credentials in a browser extension, since the extension has to hold a GitHub token to push. Before you install it, read the store listing and the extension settings rather than the repository README, because the README here is a landing page and does not document the token handling, the target repository layout or the per-site rules, and note the release state, with v1.4.21 published on 2026-09-24 and the last push the same day.

## FAQ

### What does BaekjoonHub do?

It is a Chrome extension that automatically pushes your submissions to Baekjoon, Programmers, SWEA and goorm to a GitHub repository, so solved problems are archived in version control instead of staying on the site where you submitted them.

### Which judges does BaekjoonHub support?

BOJ, Programmers, SWEA and goorm, according to the package description, and the repository topics list the same four: baekjoon, groom, programmers and swea.

### How is BaekjoonHub tested?

With the test runner built into Node, since the package test script is node --test, with the tests in a top level tests directory. Linting and formatting are handled by an.eslintrc, a.prettierrc.

### Where do I find the configuration for BaekjoonHub?

The repository README is a landing page and does not document the settings, so the extension popup, the welcome page and the Chrome Web Store listing are the places to look, with the extension manifest at the top of the repository describing what the extension declares.

### Is BaekjoonHub still updated?

The repository is not archived and the last push was on 2026-09-24, with v1.4.21 published the same day, v1.4.20 on 2026-09-23 and v1.4.19 on 2026-08-08, under the MIT licence.

## Sources

- [BaekjoonHub/BaekjoonHub on GitHub](https://github.com/BaekjoonHub/BaekjoonHub)
- [Issues](https://github.com/BaekjoonHub/BaekjoonHub/issues)
- [License: MIT](https://github.com/BaekjoonHub/BaekjoonHub/blob/master/LICENSE)
- [README](https://github.com/BaekjoonHub/BaekjoonHub/blob/master/README.md)
- [Releases](https://github.com/BaekjoonHub/BaekjoonHub/releases)

---

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