Around Go: command line · 3 MIN READ

Go toolbelt: modules, tests, vet and build

Use the native Go CLI to inspect a module and check a service before packaging it.

A useful Go development loop checks the module boundary, formatting, tests, static diagnostics and the final build. These commands are for the native Go toolchain on a development machine; platform support and build tags can change which packages are selected.

Locate the module and inspect dependencies

go version identifies the toolchain. go env GOMOD GOWORK prints selected module/workspace files without dumping every environment setting. list -m all describes the selected build list; mod why explains why a dependency is needed.

bash

go version
go env GOMOD GOWORK
go list -m all
go mod why -m golang.org/x/sync

Read the code

Run inside your module; the selected module file should be the one you expect. The last dependency is an example: if it is not required, Go explains that. Module commands may access the configured proxy and network.

Format, test and inspect suspicious code

gofmt -l lists formatting differences without rewriting files. test checks packages; -race adds supported native race instrumentation. vet reports suspicious constructs rather than proving semantic correctness. A clean run still depends on meaningful tests.

bash

gofmt -l .
go test ./...
go test -race ./...
go vet ./...

Read the code

Run each check and inspect its status. Race detection needs a supported native platform/toolchain and may require cgo; it is not available through every cross-compilation target. A race-free test run covers only paths actually exercised.

Tidy deliberately and inspect the shipped binary

mod tidy can add or remove module requirements and sums, so review its diff rather than running it as an invisible deployment step. build -trimpath removes local filesystem paths from the executable; version -m inspects embedded build/module metadata.

bash

go mod tidy
git diff -- go.mod go.sum
mkdir -p bin
go build -trimpath -o ./bin/api ./cmd/api
go version -m ./bin/api

Read the code

The example assumes cmd/api exists. Test any module file changes before committing. Embedded build metadata is useful for provenance, but build flags and source state must still be recorded for reproducible releases.

TAKE THIS WITH YOU

Check the selected module, format, test, race-check where supported, run vet and inspect the final artifact. Review dependency-file changes explicitly instead of treating tidy as a harmless read-only command.

Check your understanding

What should you do after go mod tidy?

Go to the source

Progress stays in this browser. No account needed.