Proposal: opt-in tooling to generate an offline, searchable project dataset (with a parsing bug fix)

[paulstuart]

Hi — first, thanks for maintaining awesome-go.

I've been building a Go project and wanted to consult the full list programmatically — to check whether a well-maintained library already exists before writing my own — without scraping the README each time. I put together an opt-in tool that turns the README into a structured projects.jsonl and wanted to gauge whether there's interest before proposing anything, since I know this falls outside the single-item-PR model.

What it does

• Reuses the existing goquery + markdown pipeline (no new parsing approach) to extract every project with its category and URL.
• Fetches live GitHub metrics via batched GraphQL and computes a transparent 0–100 "vitality" score (recency / popularity / issue backlog).
• Emits a deterministic, URL-sorted JSON Lines file — greppable and jq-able offline, with review-friendly diffs.
• Is fully isolated: a separate cmd/gather binary, never modifies README.md, and doesn't touch the site build or CI.

A bug I found along the way (useful on its own)

While reusing the extraction code, I hit the NextFilteredUntil("ul", "h2") FIXME: each sub-category heading swallows the link lists of every following sub-category until the next top-level ##, so projects get duplicated across categories (one project appeared under 14 categories). This also affects the generated per-category pages. The fix bounds each heading to the next heading of any level. I'm happy to submit that as a standalone bug-fix PR independent of the tooling, if you'd find it useful.

Reference implementation: https://github.com/paulstuart/awesome-go/tree/complete-vitality (structured as two commits — the bug fix first, the tooling second).

Would there be interest in any part of this — the bug fix, the tooling, or the dataset? Entirely understand if it's out of scope. Thanks!