github-rank: daily-generated leaderboards for GitHub users and repositories, built as a static site
🕷️Github China/Global User Ranking, Global Warehouse Star Ranking (Github Action is automatically updated daily).
At a glance
- What is it?
- A weekly automated pipeline scrapes and ranks GitHub accounts and repos, then renders EJS templates into a GitHub Pages site. The pipeline scripts in package.json are the whole project.
- Who is it for?
- github-rank is a scheduled ETL job with a static site attached, and it is worth reading as an example of that shape rather than as a ranking you should trust absolutely. The collection scripts are separate per data source, the render step is a single ejsc invocation over a template directory, and the published files are dist plus web, so nothing about the output depends on a running server.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 11 days ago.
- What is it written in?
- Mainly EJS, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 28, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Five collection scripts, then one render step
The npm scripts in `package.json` describe the architecture completely, which is unusual and welcome. There are five data collection entry points and one that renders the site.
"get:users": "node lib/getUsers.js",
"get:users:china": "node lib/getUsersChina.js",
"get:repos": "node lib/getRepos.js",
"get:trending": "node lib/getTrending.js",
"get:users:info": "node lib/getUserInfo.js"The umbrella `get` script chains the first three user-oriented ones together, and a separate `get:o` chains trending and repos. There is also an `get:users:ORG` entry that runs the exact same file as `get:users:china`, which reads like a leftover alias for organization accounts rather than a distinct pipeline.
The render step is one line. The `start` script runs `ejsc` over `template/*.ejs` and writes into `web`, and `ejsc` is `@wcj/ejs-cli`, a first-party package by the same author. The `package.json` field `main` points at `dist/users.json`, and the `files` array ships only `dist` and `web`, which tells you the output is data plus generated pages.
The scraping stack is older than the framework layer
Two dependencies explain the collection strategy. `cheerio` at 1.0.0-rc.12 is an HTML parser, and `@octokit/request` at 9.1.0 is a bare HTTP client for the GitHub API with no GraphQL layer on top. Having cheerio in the tree at all means at least part of the pipeline does not use the API alone.
The sensible reading is that trending data is scraped. GitHub has no public API for its trending page, so `getTrending.js` parsing HTML with cheerio is the expected approach rather than a shortcut. `getRepos.js` can use the API for star counts, and `getUsers.js` plus `getUsersChina.js` need account enumeration, which the API does not expose as a list, so a source list has to come from somewhere else.
Supporting dependencies are modest and tell the rest of the story. `node-fetch` at 3.3.1 for HTTP, `dotenv` at 16.4.0 so tokens can come from a local env file, `fs-extra` at 11.1.1 for writing output trees, `@uiw/formatter` for aligned terminal tables, and `console-emojis` for the progress output during a long fetch. The TypeScript is compiled by `tsbb` at 4.1.4, with `dev` running the same build in watch mode.
Releases on a weekly cadence with date-based versions
The release history is the clearest evidence of how this project runs. The three most recent tags are v26.9.22 published on 2026-09-22, v26.9.15 on 2026-09-15, and v26.9.8 on 2026-09-08, and each release body is a single sentence: an automated release notice. Those three dates are seven days apart, which is a weekly cadence on a fixed weekday.
The version numbers encode the date rather than a semver increment. `26.9.22` reads as year, month and day, and `package.json` agrees, sitting at version 26.9.22 to match the newest tag. The last push was on 2026-09-26, days after that release, so the repository is still receiving commits on top of the generated output.
That combination, a scheduled GitHub Action producing a dated tag, is why the project description says the ranking is updated daily while the releases are weekly. The site content moves every day; the artifact you can pin moves once a week. The repository also carries a `renovate.json`, so the dependency bumps you see in the history are automated rather than deliberate.
What the ranking measures, and what it cannot
It is worth being explicit about what a leaderboard built from this pipeline is measuring, because the answer is narrower than the site implies. The inputs are the public profile fields the GitHub API returns and the star counts on repositories, ranked and paginated into static pages. `getUsers.js` and `getUsersChina.js` produce candidate lists, `getUserInfo.js` enriches them, and `getRepos.js` and `getTrending.js` supply the repository side. Nothing in that list is a measure of influence, review quality, or how much work a maintainer does.
The repository documents no scoring methodology at all. There is no weighting file, no ranking function, and no explanation of tie-breaking anywhere in `package.json`, `src/` or the README. The only statement of intent is the description field, which says the ranking covers GitHub China and global users plus a global repository star ranking, updated daily by a GitHub Action. So the ordering logic lives either in the unquoted TypeScript or on the Pages site, and a reader evaluating whether the numbers mean anything has to go and read the code.
That is a normal position for a project of this kind, and it does not make the output wrong. It does mean the ranking should be read as a snapshot of countable public metadata at a point in time, generated weekly into dated tags and repushed daily. The repository topics include `github-api`, `github-pages`, `github-rank`, `github-star` and `segmentfault`, which is a compact description of the scope: this is a data pipeline with a front end, not an analytics product.
A README that is entirely a billboard
The most surprising thing about this repository is its README, and it is worth being blunt about it: the visible content is a banner of small icons linking to the author's commercial macOS and iOS apps, with a line at the top explaining that using one of those apps is a way to support the project. Zipora, Scap, Deskmark, Vidwall, Mousio, Musicer, Audioer, KeyClicker, DayBar and a long tail of others appear as icon rows before any documentation about rankings.
There is also a large block of HTML inline in the README rather than kept in an asset, which means the markdown file itself is mostly anchor and image tags. The actual project description, GitHub China and Global User Ranking plus Global Repository Star Ranking, comes from the repository description field rather than from the README body.
None of that is an accusation, just a structural fact: the documentation a newcomer would look for is on the GitHub Pages site at `jaywcjlove.github.io/github-rank`, and the README is a storefront. There is a Chinese README at `README-zh.md` alongside the English one, a `tsconfig.json`, an `.ejscrc.json` for the template compiler, and a `src/` directory holding the TypeScript that compiles into the `lib/` the scripts invoke.
Editorial conclusion
github-rank is a scheduled ETL job with a static site attached, and it is worth reading as an example of that shape rather than as a ranking you should trust absolutely. The collection scripts are separate per data source, the render step is a single ejsc invocation over a template directory, and the published files are dist plus web, so nothing about the output depends on a running server. The honest limitation is the input: rankings built from public profile metadata and repository stars reflect what is countable, not who is most influential. If you want to build something similar, the four get scripts and one start script in package.json are the whole architecture.
Frequently asked questions
What does the github-rank project actually collect?
Five separate collection scripts pull different things: a general user list, a China-specific user list, per-user profile information, repository data, and trending entries. The `get` script chains the three user steps and `get:o` chains trending with repositories. Data lands in `dist` and the rendered pages in `web`.
How often is the ranking updated?
The site data is described as updating daily through an automated GitHub Action, while the tagged releases land weekly on a fixed weekday. The three most recent tags, v26.9.22, v26.9.15 and v26.9.8, are exactly seven days apart and each contains only an automated release notice. Versions are date-based rather than semver.
Does github-rank use the GitHub API or scrape HTML?
Both. `@octokit/request` is in the dependency tree for API access, and `cheerio` is also there as an HTML parser. Trending data has no public API endpoint, so the trending script is the one that has to parse the page directly. The rest of the pipeline uses the API where it can.
Can I use github-rank as a library?
Not really. It is published as `@wcj/github-rank` with `dist` and `web` in its files array, which makes it installable, but the main entry point is `dist/users.json`, a data file rather than an API. The real interface is the static site. To reuse the logic you would read the scripts in `src/`.
Who maintains github-rank and under what license?
The package.json lists Kenny Wong as author with the wowohoo email address, and the license is MIT with a LICENSE file at the repository root. The project has 2,315 stars and 178 forks. The same author publishes a separate ejs template CLI, `@wcj/ejs-cli`, which is what performs the site rendering.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/jaywcjlove-github-rank)