geese: the Next.js source behind the HelloGitHub community

What HelloGitHub is, and what the geese repository actually contains

The repository is described as an open-source enthusiast community built with Next.js, and the README is bilingual with Chinese and English versions side by side.

HelloGitHub is a platform for discovering and sharing interesting, beginner-level open source projects. The community organizes projects by programming language, category and tag, and users can discover, search, favourite, comment and share the projects they are interested in, and they can like, submit and rate them so that good projects stand out.

The framing in the README is that the community gathers people who love open source, technically skilled contributors, and authors who enjoy sharing, and that the open source spirit is a way of meeting each other.

The live site is at hellogithub.com, and the README says the community is already online, with a one-click bug report link to the issue tracker.

So what the geese repository is, in engineering terms, is a full community platform rather than a component library. The name comes from the word geese, translated as a flying swan, which is meant to convey a light and quick form, and the hope is that the clean, simple interface delivers that kind of visit.

The project is Apache-2.0 licensed in the repository's own LICENSE file, and the README also carries a Creative Commons attribution-noncommercial-noderivatives licence notice for the work as a piece of content. Those are two different things covering two different things, and the distinction is worth noting if you intend to reuse either the code or the curated project descriptions.

The primary language is TypeScript, the stack is Next.js with Tailwind CSS, the last push was on 2026-09-20, and there are no GitHub releases because the deployable artefact is the site, not a package.

A Next.js project with the full community feature set already built

The package.json is where the real scope of the application shows, and it is worth reading the dependency list as a feature list.

The framework is Next.js at 12.1.6 with React 18, and the styling is Tailwind. Data fetching uses SWR, which is a reasonable fit for a site whose content changes when a moderator approves a submission rather than on a fixed schedule.

The community features map to specific libraries. SortableJS at 1.15.0 handles drag to reorder, which is how a ranking of projects is likely to be built. react-infinite-scroll-hook handles paginated lists. react-markdown with remark-gfm and react-syntax-highlighter render the project descriptions, and the syntax highlighter is what makes a code snippet in a README look right in a card. classnames and clsx are both present, which is a small duplication worth noticing. ECharts with echarts-for-react covers the charting, and rc-util supplies the Ant Design utility components. React Icons provides the icon set.

Internationalisation is done with i18next at 23, next-i18next, react-i18next, and the repository carries a next-i18next.config.js alongside a next-sitemap.config.js for sitemap generation. dayjs handles dates, js-cookie and cookie-parser handle cookies, copy-to-clipboard is the share button, and nprogress is the progress bar. pino-http is the request logger.

The server side is Express with a server.js at the root, and pm2 appears in the scripts rather than the dependencies because it is expected to be installed globally.

So the application is a complete implementation of the feature list in the README: browse by language, category and tag, search, favourite, comment, like, submit and rate. Someone starting a similar site would find the whole thing already wired.

The scripts, and how the site is actually run in production

The scripts block in package.json tells you the whole development and deployment workflow in twenty lines.

Development is cross-env NODE_OPTIONS with the inspect flag set running next dev, so the dev server starts with the Node inspector attached. Building is next build, and the build:dep variant sets ANALYZE with the bundle analyzer dependency to show where the client bundle weight goes.

Then there is a set of server scripts, and this is the interesting part. The project does not assume a platform as a service. server_start runs pm2 start with ecosystem.config.js, server_reload builds the app, regenerates the sitemap and then reloads pm2, and server_stop stops it. That is a process manager workflow, which is the shape of a self-hosted deployment.

The linting and typing are strict. next lint is the basic pass, lint:fix runs eslint on src with a fix and then formats, and lint:strict runs eslint with --max-warnings=0, so a warning fails the same as an error. typecheck runs tsc with noEmit and incremental disabled, which is the setting to use in CI where a stale build cache would hide a type error.

The test setup is jest, with a watch variant, and jest.config.js and jest.setup.js at the root. The formatting is prettier with both a write and a check mode, the commits go through commitlint with a commitlint.config.js, and the release process is standard-version with a push-release script that pushes the tags and the main branch. Husky installs itself in a prepare script, and there is a .husky directory and a .prettierrc.js.

The combination of standard-version, commitlint and a strict lint script is the standard modern JavaScript release setup, and it is the part of this repository most worth copying if you are building something similar.

The Docker image, and one registry detail worth changing

The Dockerfile is short and reveals the production shape.

It starts from the official Node.js Alpine image, sets the working directory to /usr/app, and installs PM2 globally with an explicit registry flag pointing at registry.npm.taobao.org. The package manifests are copied first so the dependency layer is cached independently of the source, then the rest of the tree is copied in.

The build runs yarn config set registry with the same taobao registry, then yarn, then yarn build. The container then drops privileges: the USER directive switches to the node user, with a comment noting that the node user is provided by the base image. The port exposed is 8888.

And the entrypoint is pm2-runtime starting ecosystem.config.js, which is the Docker-aware way to run PM2 as PID 1 so that signals reach the process manager and the container stops cleanly.

The non-root user is the detail that shows care. A Next.js server does not need root, and the comment makes the reason explicit rather than leaving it as an unexplained USER line.

The registry is the detail that needs attention. The taobao registry was the standard mirror for users in China, and it makes sense given the project's origin and audience, but it is now a legacy service and pointing your build at it will either slow the build down or fail it. Changing it to the default npm registry, or to whatever mirror you trust, is a one-line change in the Dockerfile and in the PM2 install line above it.

There is also an ecosystem.config.js at the repository root, which is the PM2 process definition, and the Dockerfile relies on it for the container entrypoint.

How the project invites contributions

The contribution model is the part of this repository that differs most from a typical open source project, and it is worth reading because it is unusual in a good way.

There is a section of unclaimed work with checkboxes, listing two open issues by name. The first is reducing the size of the project bundle, marked as complex, and the second is a list of unresolved problems, marked as simple.

The linking is direct. Each entry points at a specific GitHub issue, and the issue titles carry the difficulty label in brackets, one marked complex and one marked simple. The next open issue in the list is titled the simple unresolved problems.

The expectations for a contributor are spelled out in three numbered requirements. You need a personality that loves open source, follows through, and is reliable. The completion time is up to you, with reference figures of 7 days for simple, 14 for medium and 30 for complex. And any questions go in the issues under the corresponding requirement, so the discussion stays next to the work.

The developer notes are in a content file in the docs directory, and the README thanks the contributors through a contributors graph link.

The pattern here is a task board rather than a contribution guide. For a community site whose backlog is small and well understood, that works better than a long document: a newcomer opens the repository, sees two named issues with difficulty labels and reference timeframes, picks one, and asks questions in the issue itself.

The repository layout supports the same story, with a data/ directory that is likely the project catalogue content, a docs/ directory holding the developer notes, a public/ directory for static assets, and an .env.development file for local configuration.

Editorial conclusion

Adopt geese if you are looking for a complete Next.js application to study or to fork for a project directory or community site, since it includes search, favourites, comments, ratings, i18n and a PM2 based deployment. Do not adopt it as a fresh dependency, because the source is the deliverable and the package is private. Before you run it, read the developer notes in the docs directory, and note that the Docker build and the PM2 install script both point at the npm.taobao.org registry, which you may want to change to the default npm registry.

Frequently asked questions

Official sources

1. HelloGitHub-Team/geese on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README