Data & method

Three things get settled here: where the data comes from, what stops a repository from being listed, and what each badge actually claims. Without those, a ranking is just noise.

Source and scale

Data updated

2026-11-05 01:05 UTC (this build ran 2026-11-05 05:05 UTC)

Search queries

language:zig stars:>=10 / language:zig stars:>=200

Unique repositories

2451 (deduplicated by repository id across queries)

Projects after merging

2451, of which 0 had the same project on more than one host

Listed

1516

build.zig.zon

1556 parsed, 63.5% coverage; 45.5% of the whole set declare a minimum Zig version

Dependency graph

704 edges pointing at 450 distinct targets

Star growth

not computed — 1 snapshot on file, and the window needs two at least 2 days apart

Why mirrors are merged before anything is ranked

Stars on different hosts are not comparable, so they must never sit next to each other in one list. A concrete case: ziglang/zig shows 43,258 stars on GitHub and 6,997 on Codeberg, and Codeberg is where the original lives now. Without merging, a mirror would occupy the top slot and every conclusion drawn from the order would be wrong. The merge key is the upstream URL declared in the repository description (“mirror of …”, “moved to …”); when that is missing it falls back toowner/repo with mirror prefixes and suffixes stripped.

What the listing gate filtered out:

The composite score

score = 0.35 × normalized(log(stars))
      + 0.20 × normalized(star growth over the snapshot window)
      + 0.20 × activity (exponential decay on days since last push, 180-day half-life)
      + 0.15 × normalized(log(dependents))
      + 0.10 × maintenance health

The growth window is pinned to about 7 days: the baseline is whichever stored snapshot sits closest to one week before the newest, rather than the oldest one on file. That matters because the meaning of “growth” would otherwise drift with how often the crawler happens to run — after three months of weekly crawls an oldest-vs-newest diff is a quarterly number wearing a weekly label. Until two snapshots at least 2 days apart exist, the growth term is dropped and its weight is redistributed rather than scored as zero. Scoring it as zero would push every newly indexed project to the bottom for a reason that has nothing to do with the project. This is the only place where missing data changes the formula.

Maintenance health is a proxy: license present, description present, number of topics, a plausible fork/star ratio, a homepage, issues relative to stars. Fetching contributors per repository would need API budget that is not available, so it is not part of it.

What each badge claims

Coverage is 63.5%, which means for 36.5% of indexed projects this index cannot give you any version conclusion at all. That is the honest ceiling of the current data, and the main reason the “CI build passed” badge is on the roadmap rather than in the copy.

Known limits

• GitHub’s language:zig is decided by byte count, so a repository becomes “Zig” the moment its .zig files outweigh everything else — and a project written in Zig with a C binding layer may not. Two queries (language, plus the zig topic) are unioned to soften this; per-file ratios are not computed.
• Categories are keyword-weighted, so beyond the head of each list you will find misfiled projects. Every project page publishes the evidence that matched and its confidence, which is what makes those errors reportable.
• Stars are not quality. The default order is the composite score, and the gate removes mirrors and stalled repositories before anything is ranked.
• Gitee is not included. Searching “zig” there returned 1,090 results of which 18 of the top 20 were zero-star mirrors — the signal-to-noise ratio would make the index worse, not better.
• Every version statement on this site is declaration-level until the build test exists.

How often this refreshes

The full crawl — repository metadata, then every build.zig.zon — takes about ten minutes of machine time and costs nothing, so the cadence is set by what actually changes, not by budget. Repository metadata is re-crawled weekly. Manifests are re-fetched when a cache entry passes28 days, because a project adding minimum_zig_version later is the one change that silently moves someone off the “Needs Zig ≥ X” badge. A new Zig stable release is not a calendar event: it re-labels every declared floor at once, so the version table and the compatibility pages are rebuilt by hand on the day it lands, independent of the schedule.

Rebuilding without re-crawling is treated as a defect, not a shortcut: the pages publish the crawl date rather than the build date, and the artifact check fails if the two have drifted more than 10 days apart.

Roadmap

• P1: keep the weekly star snapshot running so the 7-day growth window always has a baseline; index Codeberg in full and deduplicate by canonical key.
• P2: run a zig build matrix in CI for the head of each category, which is what turns “Declared floor” into “CI build passed”; extend the dependency graph to downstream reach.
• P3: gap reports — which categories still have no usable library — fed back to awesome-zig and to the authors.

What this is not

Zig’s maintainers have said they will not run a central package index. ZigScout does not claim to be official, does not speak for the Zig team, and does not sell placement or inflate stars. Everything here comes from public APIs, collected within each platform’s rate limits.

The Chinese version of this page is at /zh/about.