feat: auto-update star count

[panva]

Summary

• Update the library-data generator to refresh star counts directly in src/data/libraries-next.json.
• Refresh star counts before production deployments.
• Redeploy production weekly to keep counts current.

Details

• Remove the stale remote data source and unused libraries.json output.
• Authenticate locally with GITHUB_TOKEN, including tokens from gh auth token.
• Deduplicate repositories before querying GitHub and use bounded concurrency.
• Support entries linking to paths within a repository.
• Warn and retain the existing count when an individual repository lookup fails.
• Write the updated data atomically after processing all repositories.
• Use the workflow’s built-in GitHub token with read-only permissions.
• Refresh counts before the main and community production deployments.
• Add a weekly Monday 06:00 UTC production deployment and manual workflow trigger.
• Document local and automated usage.

[jonathanp-okta]

Thanks for this — nice simplification. Confirmed there's no new secret here: ${{ github.token }} is the auto-issued, read-only Actions token (scoped down explicitly to permissions: contents: read), replacing the old GitHub App credentials. It's only used to call the public GET /repos/{owner}/{repo} endpoint for star counts, so no elevated access is needed.

I traced the diff against the current app code (src/middleware.ts, src/app/[language]/libraries/page.tsx) to confirm src/data/libraries-next.json is the live file the site actually reads — it is, so this isn't touching a dead path. Logic checks out: dedup by repo, atomic write (temp file + rename), graceful per-repo failure handling via Promise.allSettled, and prettier/octokit are already existing deps so no lockfile changes needed.

A few things I'd like to resolve before merging, given this touches the production deploy path directly:

1. This now sits in the critical path of every production deploy

generate:library-data runs as a step in Deploy-Production before vercel deploy --prod, on every push to master/production, not just the weekly schedule. If authenticateGitHubToken() throws (token/API auth failure) or the file read/write throws, the step fails and the deploy is blocked entirely — even for changes completely unrelated to libraries data.

• Is that intentional, or should this step be non-blocking (e.g. continue-on-error: true, or only hard-fail on file corruption and treat API/auth failures as a warning)?
• Individual repo star lookups already degrade gracefully (warn + retain old count), so this is really just about the top-level auth check / file I/O.

2. Refreshed star counts aren't committed back to git

The updated libraries-next.json only exists in the ephemeral runner checkout that gets uploaded via vercel deploy — the committed file in the repo stays stale until someone runs the script locally and commits. Confirming this is expected/acceptable, since the README doesn't currently call this out.

3. Duplicate work on production branch pushes

Both production.yaml and preview-community.yaml trigger on push to production and each independently re-fetch the same star counts. Not a bug, just doubles the GitHub API calls per push — worth being aware of if the library list grows a lot.

Minor / non-blocking

• @octokit/auth-app is no longer used anywhere in the codebase but is still in package.json — could drop it here or in a follow-up.
• No unit tests for the script (wasn't the case before either, but the rewrite is substantial enough that a couple of tests around collectLibrariesByRepository / updateStarCounts would be valuable given it now runs unattended before every prod deploy).

None of the above look like correctness bugs — the main ask is just to double check the failure-mode behavior in #1 so a transient GitHub API hiccup can't accidentally block shipping to production. Happy to approve once that's addressed or confirmed intentional.

[panva]

@jonathanp-okta

Is that intentional, or should this step be non-blocking (e.g. continue-on-error: true, or only hard-fail on file corruption and treat API/auth failures as a warning)?

Yes, it is intentional, because the followup to this would be to drop the stale star count from the repo.

Refreshed star counts aren't committed back to git

This is intended in order to keep the permissions read-only. writing back to the repo would require a write step with write permissions and with the followup dropping the star count from the repo-tracked file it is the only logical step.

@octokit/auth-app is no longer used anywhere in the codebase but is still in package.json — could drop it here or in a follow-up.

I can do a cleanup together with the committed star-count removal.

[jonathanp-okta]

@jonathanp-okta

Yes, it is intentional, because the followup to this would be to drop the stale star count from the repo.

This is intended in order to keep the permissions read-only. writing back to the repo would require a write step with write permissions and with the followup dropping the star count from the repo-tracked file it is the only logical step.

I can do a cleanup together with the committed star-count removal.

Makes sense, thanks for the context — the two-step plan (blocking now, drop stars from git + cleanup @octokit/auth-app in the follow-up) is coherent, good to merge this as-is.

One thing to plan for in that follow-up: Vercel's own automatic PR preview builds (the "Preview" deployment shown on PRs) build directly from the branch via Vercel's GitHub integration — they don't run these Actions workflows, so generate:library-data never executes there. Once stars is dropped from the committed libraries-next.json, every PR preview will render the star icon with no number (library-card.component.tsx:146 has no fallback for undefined/null — won't crash, just looks broken).

Worth deciding then whether that's acceptable, or whether previews need either a placeholder/hide-if-missing state in LibraryCardComponent, or their own generate step.