Thanks for wanting to contribute. Here's what you need to know.
git clone https://github.com/phlx0/ghscope
cd ghscope
go build . # produces ./ghscope
go test ./... # run testsA GITHUB_TOKEN with public_repo read scope speeds things up a lot — without it you're rate-limited to 60 req/h. Set it in your shell or run ./ghscope setup after building.
main.go entry point, cobra commands
internal/
api/ thin GitHub API wrappers, each with disk-cache support
analysis/ pure computation on top of the API data
ui/ Bubble Tea model, tab views, setup wizard
cache/ SHA256-keyed JSON file cache (~/.cache/ghscope)
config/ ~/.config/ghscope/config.json
geo/ IP → country resolution for stargazers
The layering matters: api never imports analysis, analysis never imports ui. Keep it that way.
- Add an API call in
internal/api/— always cache the response with a sensible TTL. - Compute the stat in
internal/analysis/— export the type fromtypes.go, add the module constant toModuleOrder. - Wire the goroutine in
analysis/run.go— calldone(ModuleXxx, err)at the end. - Add
internal/ui/tab_xxx.gowith arenderXxx(s *analysis.RepoSummary, w, h int) stringfunction. - Register the tab name in
ui/model.goand add acase "Xxx":in the view switch.
- No comments except where the why isn't obvious from the code
- Unexported helpers are fine; don't export something just because it might be useful later
- Tests live next to the code they test (
foo_test.goin the same package) - Commit messages: lowercase imperative, no period —
add trending signal to overview
Install VHS, then:
make demoThis writes demo/demo.gif.
- Keep PRs focused — one thing at a time
- If you're adding a new API call, note the approximate call cost in the PR description
- Existing tests must pass; new analysis code should have at least one test
Open a discussion or an issue — both work.