Add github-repo-stats.html: GitHub repo info dashboard

[simonw]

Given a GitHub repo URL or foo/bar repo ID show information about that repo absorbed via wither REST or graphql CORS fetch() including the number of commits in the repo and other useful stats

Given a repo URL or owner/repo, fetches comprehensive stats from the
GitHub REST API (CORS) including total commits, contributors, branches,
tags, releases, open PRs, language breakdown, top contributors, and
latest release. Uses the per_page=1 + Link header trick to derive total
counts cheaply. Supports optional GitHub token auth via localStorage to
raise the rate limit.

https://claude.ai/code/session_01QcwZhpETRU2HSuXwmC7S7p

[claude]

Claude finished @simonw's task —— View job

---

PR Review Complete ✅

I've thoroughly reviewed the GitHub repo stats dashboard implementation. Here's my comprehensive feedback:

Todo List

• Read repository guidelines (CLAUDE.md) - No CLAUDE.md found
• Analyze github-repo-stats.html implementation
• Review github-repo-stats.docs.md
• Evaluate code quality and best practices
• Check for potential bugs and issues
• Assess performance considerations
• Review security concerns
• Evaluate test coverage needs
• Provide comprehensive feedback

🟢 Overall Assessment

This is a well-implemented, single-file GitHub repository dashboard that effectively leverages the GitHub REST API. The code demonstrates good practices for client-side development and clever optimization techniques.

✅ Strengths

Code Quality & Best Practices

• Clean, readable code structure with clear separation of concerns
• Consistent naming conventions and appropriate comments
• Modern JavaScript using ES6+ features appropriately
• Semantic HTML with proper accessibility considerations
• Mobile-responsive design with thoughtful breakpoints
• Progressive enhancement with graceful error handling

Performance Optimizations

• Clever pagination trick using per_page=1 + Link header parsing (github-repo-stats.html:287-310) - excellent optimization to get counts without fetching all data
• Parallel API requests using Promise.all() (github-repo-stats.html:375-396) - minimizes total load time
• Lazy loading for contributor avatars (github-repo-stats.html:441)
• Efficient DOM manipulation with single innerHTML updates rather than multiple DOM operations

Security Considerations

• Proper HTML escaping via escapeHtml() function (github-repo-stats.html:340-344) prevents XSS
• Safe external links with target="_blank" rel="noopener" (github-repo-stats.html:419)
• Token storage in localStorage is appropriate for this use case
• CORS-compatible design using GitHub's public API

⚠️ Areas for Improvement

Security & Error Handling

1. Token validation missing - No validation that stored GitHub token is valid format before use (github-repo-stats.html:277-279)
2. Rate limit handling could be more graceful - Currently shows generic error message (github-repo-stats.html:370)
3. Network error resilience - No retry mechanism for transient failures

Code Quality

1. Large function complexity - The render() function (github-repo-stats.html:410-512) is quite long and handles multiple concerns
2. Magic numbers - Hard-coded values like contributor limit of 8 (github-repo-stats.html:394)
3. URL parsing could be more robust for edge cases (github-repo-stats.html:266-273)

User Experience

1. Loading state could be more detailed - Shows generic "Loading..." without progress indication
2. No caching - Repeated requests for same repo will hit API unnecessarily
3. Limited error context - Some error messages could be more actionable

🚨 Potential Bugs

1. Anonymous contributor handling (github-repo-stats.html:437-439) - Edge case where anonymous contributor might not have expected fields
2. Division by zero potential in language percentage calculations if langTotal is 0 (though this is protected)
3. Date parsing assumes ISO format (github-repo-stats.html:326) without error handling for malformed dates

📊 Performance Considerations

Excellent: The pagination Link header trick is a brilliant optimization that reduces API calls dramatically.

Good: Parallel requests minimize wait time effectively.

Suggestion: Consider adding:

• Request caching for repeated queries
• Request debouncing for rapid user input
• Progressive loading indicators for slow connections

🧪 Test Coverage

Current State: No automated tests present (typical for single-file tools).

Recommendations:

• Unit tests for utility functions like parseRepo(), fmt(), escapeHtml()
• Integration tests for API response handling
• Manual testing checklist for various repo types (private, archived, empty, etc.)

🔒 Security Assessment

Overall: Security posture is good with proper XSS prevention and safe external link handling.

Minor concerns:

• Consider validating GitHub token format before storage
• Add Content Security Policy headers if serving from a web server
• The external auth popup (github-repo-stats.html:250) assumes the auth service is trustworthy

📝 Specific Code Suggestions

1. Add token validation (github-repo-stats.html:277-279):

if (token && /^gh[ps]_[A-Za-z0-9]{36,}$/.test(token)) {
  headers['Authorization'] = `token ${token}`;
}

2. Break down render function - Consider splitting into smaller functions for maintainability

3. Add rate limit info - Parse X-RateLimit-Remaining header to show user their remaining quota

🎯 Conclusion

This is a solid implementation that effectively solves the stated problem. The clever optimization techniques demonstrate good understanding of the GitHub API, and the code quality is high. The security considerations are well-handled, and the user experience is smooth.

The concerns raised are mostly minor refinements rather than critical issues. This tool would be valuable as-is and represents excellent work.

Recommendation: ✅ Approve - Ready to merge with optional follow-up improvements.