Don't couple your Go code to GitHub
- ID
- 29200
- Status
- summarized
- Published
- 28 Sep 2026, 12:50 AM
- Fetched
- 28 Sep 2026, 12:16 PM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://iain.rocks/blog/dont-couple-your-go-code-to-github
- Source URL
- https://hnrss.org/best
Summary
- Score
- 7.0
- Created
- 28 Sep 2026, 12:17 PM
- Tags
- Audience
- developerssaas_founders
What happened
Iain Cambridge argues that Go's convention of namespacing imports by fetch location (e.g. import "github.com/thetrueares/boneclone") hard-couples code to a git host, and recommends vanity domains such as go.iain.rocks, go.uber.org and go.mongodb.org that can be repointed later. He cites a company running GitLab, GitHub and Azure DevOps at the same time because rewriting import paths was too costly, and says he built Boneclone to replicate skeleton code across multiple git hosts. The post ships his nginx config, which serves the Go tool's ?go-get=1 requests and 301-redirects human visitors to GitHub.
Why it matters
If you maintain internal Go modules, this is a decision you make once: a vanity domain plus the nginx location block he publishes (branch on $args !~ go-get=1, redirect humans, try_files for the tool) means a future git-host migration changes a DNS record instead of every import line in every repo. The cited three-host company shows the alternative cost is real money and real lock-in, so the useful action is to set the domain up before you have hundreds of modules, not during a migration.
Discussion angle
Does a vanity import domain trade a git-host dependency for a DNS/domain-ownership dependency — who in the team actually renews it, and what breaks for downstream users the day it lapses?