The www build saves failed GitHub star requests as zero, which the
navigation displays as `0K`. This passes `GITHUB_TOKEN` through Turbo's
build environment and preserves a valid previously generated count when
a request fails.
If there is no valid previous count, the navigation displays “GitHub”
and the homepage contribution graphic omits the number. Cached fallback
is available only when the previous generated content exists; rate
limiting is a possible cause of the original failure, but has not been
confirmed from deployment logs.
## To test
- Run `pnpm --filter www exec vitest run
scripts/lib/githubStars.test.ts` — all 16 tests pass, covering
authenticated and anonymous requests, rate limiting, malformed
responses, and missing or invalid cached content.
- Build with a valid `GITHUB_TOKEN` and check that the navigation and
homepage graphic show the star count.
- Simulate a failed GitHub request with and without existing generated
content. Confirm that a valid previous count is retained, or that no
zero count appears when none is available.
Verified locally: live GitHub fetch through the new loader, Turbo dry
run with strict environment filtering and `GITHUB_TOKEN` allowed,
Prettier, and ESLint (one existing default-export warning). Full build
and browser checks have not been run.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Bug Fixes**
- GitHub star counts are now displayed only when valid; otherwise, the
interface shows a clear fallback label.
- Star counts can fall back to cached data when GitHub is unavailable or
returns invalid results.
- Builds without GitHub data now complete gracefully instead of failing.
- **Tests**
- Added coverage for authenticated and unauthenticated requests, cached
fallbacks, invalid responses, and clean builds.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
