A pull request's go.mod lost a require line after `go mod tidy` — how do you decide it is safe?

## Why the question is not rhetorical `go.mod` diffs are the part of a pull request people skim. They look like generated noise, and mostly they are — but a removed `require` line is one of the few module-level changes that can alter what compiles without anyone editing a line of Go. Reviewing it well is a small, learnable procedure. ## The rule the tool followed `go mod tidy` removes a requirement when **no package in the main module, and no test of one, needs that module** — evaluated across build tags and target platforms, and including modules named by `tool` directives. So a removal is a claim: *nothing reaches this any more.* Your job is to decide whether that claim is true for the code as it will exist on the main branch. ## The four checks **1. Find the cause in the same diff.** A removed direct requirement should pair with a removed import. If the pull request deletes `import "example.com/httpx/client"` and the `example.com/httpx` require disappears, the story is complete. If no import left, something else explains it, and you need to know what. **2. Reproduce it.** Check out the branch and run `go mod tidy` with the Go version the repository expects, then `git status`. If tidy produces further changes, what was committed is not a tidy result — it was hand-edited, produced by a different toolchain, or produced from a different working tree. **3. Ask who needs it.** `go mod why -m example.com/httpx` should print `(main module does not need module example.com/httpx)`. If instead it prints a chain of packages, the requirement is still reachable and the removal will not survive the next tidy — or worse, the branch was tidied with a file missing. **4. Diff the build list.** This is the check people skip and the one that catches real breakage: ``` git checkout main && go list -m all > before.txt git checkout branch && go list -m all > after.txt diff before.txt after.txt ``` A removed *direct* requirement usually shows up here as that module leaving the list — expected. A removed **indirect** requirement is the interesting case: an indirect line records a minimum version, and deleting it can let some other module resolve **lower** than it did before. A build list diff that shows an unrelated module moving down is the signal to stop and ask why, because a silent downgrade re-introduces bugs the team already fixed. ## Innocent explanations that are not the visible import When no import left the diff, the usual causes are: - the `go` line changed in the same pull request, so the requirements were re-derived under different rules; - a build-tagged file, or a whole test file, was deleted, taking the only import of that module with it; - a `tool` directive was removed, so an executable dependency is no longer tracked; - the branch was tidied by a different Go toolchain than everyone else uses. All four are legitimate; each one changes what you should check next, which is why identifying the cause comes before approving. ## Build it the way it will ship Tidy reasons about every platform; a local `go build ./...` reasons about one. If the service ships for a different GOOS or GOARCH than the reviewer's laptop, or has code behind build tags, run the build for those targets — `GOOS=linux GOARCH=arm64 go build ./...` — or rely on a CI matrix that does. "It compiles for me" is not evidence about the code paths tidy considered. ## Make it stop being a judgment call The durable fix is to remove the ambiguity from review entirely: - CI runs `go mod tidy` and fails when go.mod or go.sum then differ, so every committed module file is provably tidy; - the Go version used in CI is fixed, so tidy is deterministic across contributors; - CI compiles and tests the full platform matrix, so tidy's broader view is actually exercised; - optionally, CI prints the `go list -m all` diff against the base branch on every pull request, which turns "did any version move?" from an investigation into a line in the build log. With those in place, a lost `require` line becomes a one-glance review: the import is gone, the build list moved the way it should, and the pipeline agrees.