wargabantuwarga.com republishes Google Docs as a fast COVID-19 information site

A republicator, not a content management system

Warga Bantu Warga describes itself as a society initiative to circulate information about health facilities and devices for COVID-19, and the README states the purpose precisely: the website republishes publicly accessible Google Docs to make them more mobile-friendly and performant. That single sentence explains both the value and the ceiling of the project. The content lives in Google Docs, which is why the contributors can collaborate without a conventional CMS, and the site exists to fix the two things a Google Doc does badly on a phone over a slow connection, which is rendering and load time. The site is at wargabantuwarga.id, the primary language is TypeScript, the licence is MIT, and the repository is not archived with a last push on 2026-09-13. There are no GitHub releases, so version tracking happens through the commit history and the package.json version field, which reads 0.1.0. The topics list gives the shape of the stack: nextjs, react, tailwindcss, cypress, react-testing-library and website, alongside covid-19 and hacktoberfest.

How the data moves from a Google Doc to a static page

The pipeline is visible in package.json rather than in prose. The script fetch-wbw runs ts-node etc/fetchers/fetch-wbw.ts, and a companion script fetch-database runs ts-node etc/fetchers/fetch-database-only.ts, which tells you that the fetch step is split into at least two modes, one that pulls the whole document set and one that only pulls the database. The build script runs next build, and the postbuild hook runs next-sitemap followed by ts-node etc/create-sitemap-index.ts, so a sitemap index is generated after every build rather than maintained by hand. The production path is explicit in the netlify-export script, which runs yarn fetch-wbw, then yarn build, then next export, producing a static export with no server component. The dev script is NODE_OPTIONS=--openssl-legacy-provider next, which is the usual accommodation for the OpenSSL 3 provider change on Node 17 and later. The data/ directory and the _content/ directory at the top level are where the fetched content and the site copy live, and wb.config.js is the configuration file that ties the fetchers to the site.

Running it locally in three commands

The Getting Started section gives a short and complete path. First you clone the repository, then you install dependencies and fetch the data, and finally you start the development server.

git clone https://github.com/kawalcovid19/wargabantuwarga.com.git

The README is explicit that the project uses Yarn and not npm, which is the kind of detail that costs an afternoon if you miss it.

cd wargabantuwarga.com
yarn install
yarn fetch-wbw

The fetch step is not optional, because without it the pages have no data to render. Then the development server starts.

yarn dev

You open http://localhost:3000 in a browser to see the result. Note that the dev server binds to port 3000 by default, and that the fetch-wbw script reaches out to Google, so the first run needs network access to the source documents.

Performance, accessibility and a one hour staleness budget

The README is unusual in writing down what the project refuses to do. Four principles are listed: performance, accessibility, up-to-date information and iterative incremental changes, and four things are rejected: counter-productive cosmetics, expensive functionalities and unmeasured improvements, plus the framing that less moving parts means less error and less maintenance burden. Two of these are worth reading closely for anyone who wants to reuse the codebase. The up-to-date principle states that any information posted must match the latest version the content editors published, and that delays can be tolerated for the sake of web performance but should be limited to less than an hour, which is a concrete operational commitment rather than a slogan. The unmeasured improvements principle says that for any change to the site the impact on Core Web Vitals should be measured continuously, and that a change proven to hurt the metrics should be reverted. The example given for an expensive functionality is Google Analytics, tracked as an issue in the repository, which shows the project treats third-party scripts as a performance cost rather than a free win.

The test stack: Jest, React Testing Library, Cypress and Playwright

Testing is the part of the repository with the most tooling for its size. jest.config.js and a __tests__/ directory hold unit and component tests, and the topics list names react-testing-library, which the README's testing guidelines are written around. Those guidelines are three rules, and they are stated as rules rather than suggestions: prefer query priorities, test appearance and disappearance rather than presence alone, and opt in for interactions instead of firing raw events. Cypress appears in the tree with cypress.json and a cypress/ directory, and package.json exposes cypress:open and cypress:run for the interactive and headless modes. Playwright is present too, with playwright.config.ts and the e2e and e2e:ui scripts, so end to end coverage is duplicated across two frameworks. The test:e2e scripts use start-server-and-test to boot the dev server against http://localhost:3000 and then run Cypress, and the test script uses is-ci to switch between coverage mode and plain Jest. Other scripts cover lint, format, type-check and analyze, with the bundle analyzer enabled through cross-env ANALYZE=true. Commit hygiene is enforced by husky, commitlint.config.js and the cz script for conventional commits.

Deployment shape and what the CI badges mean

The README badges point at four workflows in .github/workflows. There is a test workflow, a deploy workflow, and a Lighthouse CI check against the production site, configured by lighthouserc.js, which is the automation behind the performance principle. The netlify.toml file and the presence of @netlify/plugin-nextjs in the dependencies point at Netlify as the host, and the supporters section names Netlify, GitBook and Cypress as supporting the project. The site also uses next-pwa, so the site can be installed as a progressive web app, and next-seo for metadata. The repository carries an .amp/ directory for accelerated mobile pages and a next-sitemap.js configuration, which is consistent with a project that treats crawlability and mobile performance as first-class concerns.

Where this repository is the wrong tool

The limits are structural rather than fixable. The first is the dependency on publicly accessible Google Docs, which is the stated purpose but also the failure mode: if a contributor makes a document private, renames it or moves it, the fetch step stops finding it and the build either fails or ships a page with stale content, and the one hour staleness budget is what turns that into a visible problem rather than a background one. The second is that there is no editorial interface at all, so every change goes through the fetch, the build and a deploy, which means the fast editing loop that Google Docs offers is where the work happens and the site is a rendering layer, not a place where content is authored. The third is that it is a specific dataset, not a framework: the fetchers are named for this project, wb.config.js points at this project's sources, and generalising them is a rewrite rather than a configuration change. The fourth is operational, since a static export with a one hour freshness promise depends on the build host running reliably, and the README does not describe any fallback if the build or the fetch fails. The fifth is that the project is a community initiative for Indonesian COVID-19 information, so its licence, its tone and its content decisions are all tied to that purpose. If you want a general purpose publishing platform, the honest comparison is with a static site generator plus a CMS, which gives editors a real interface and removes the Google Docs dependency at the cost of the very simplicity that makes this project easy to run.

Editorial conclusion

Adopt this repository if you are a community team that needs to publish frequently changing public health information to a low bandwidth audience and your contributors already work in Google Docs, because the fetch and build pipeline is the part that carries the value. Do not adopt it as a general purpose content platform or as a starting point for a product with an editorial back office, since there is no CMS, no admin interface and no account system behind it. Verify two things before you rely on it: that the source documents you depend on remain publicly accessible in Google Docs, because the fetch step breaks the moment a document is made private, and that your own build host can run the export, since the production path is a static export rather than a long-running server. The practical first step is to run yarn install, yarn fetch-wbw and yarn dev locally and compare the local output against the published site before you change any content.

Frequently asked questions

Official sources

1. Issues
2. kawalcovid19/wargabantuwarga.com on GitHub
3. License: MIT
4. Project website
5. README