shekhar/windows-iso-downloader
1
0
Fork 0
Code Issues Pull requests Projects Releases 15 Packages Wiki Activity Actions
windows-iso-downloader/CONTRIBUTING.md
Shekhar Vaidya 4bb0ba9f2a docs: add CONTRIBUTING.md 
Moves the README's inline contributing notes into a dedicated file
and expands them with dev setup, PR conventions, and how CLI releases
work, so contributors have one place to look.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-07-13 11:00:46 +05:30

2.4 KiB
Raw Blame History

Contributing to MSDL

Thanks for considering a contribution. This project is a small, community-run tool — bug reports, product additions, and fixes are all welcome.

Reporting bugs

Open a GitHub issue. Include:

  • Whether you hit it via the web app, the CLI, or both
  • CLI version (msdl --help prints it) or which page on msdl.tech-latest.com
  • The exact error message, if any
  • Product/language you were trying to fetch

Development setup

See the README's "Running Locally" section for backend and frontend setup. For the CLI:

cd cli
go run . --help
go test ./...

Adding a new consumer Windows release

  1. Find the product ID at www.microsoft.com/software-download-connector/api/
  2. Add it to frontend/public/data/products.json (name, archs, badge, related, active)
  3. Add it to cli/catalog.go's consumerProducts slice
  4. Update the product table in README.md

Adding a new evaluation edition

  1. Find the fwlink URL at microsoft.com/en-us/evalcenter/download-*
  2. Add the slug and fwlink to the evalProducts map in backend/main.go
  3. Add the same slug to cli/catalog.go's evalProducts slice
  4. Add the product config to frontend/src/data/evalProducts.ts
  5. Update the eval table in README.md

Making changes

  • Small, one-line config fixes can go straight to main.
  • Anything touching behavior (new feature, bug fix, refactor) should go through a feature branch and PR.
  • Test locally before opening a PR — build and run the affected component (go build, go test ./..., npm run dev) rather than relying on review to catch it.
  • Commit messages follow Conventional Commits: feat:, fix:, docs:, chore:.
  • Keep PRs focused — one fix or feature per PR, not a bundle of unrelated changes.

CLI releases

CLI releases are cut by the maintainer via git tag (cli/vX.Y.Z), which triggers the GitHub Actions build for all platforms and the winget package update. Contributors don't need to worry about tagging, versioning, or winget — just get the fix or feature merged to main.

Code style

No linter is enforced yet — match the surrounding code's style (Go: stdlib-first, minimal dependencies; frontend: existing Tailwind/component patterns). Don't add abstractions, comments, or error handling beyond what the change actually needs.