In a Go module, what does the ./... pattern match, and what does go build ./... leave on disk?

## The pattern language The go command's arguments are **package patterns**, not file paths. `.` is the package in the working directory, `./cmd/api` is a package below it, and `...` is a wildcard that matches any sequence of path elements. So `./...` means "this package and everything under it", and `./cmd/...` narrows that to the commands. Two boundaries matter: - **`./...` stays inside the main module.** It expands over the directory tree of the module you are in, so dependencies are never matched — they are compiled as needed, but they are not part of the pattern. The pattern that spans dependencies is `all`, which means every package transitively imported by the main module's packages. - **Some directories are skipped.** A directory with no Go files contributes no package. Directories named `testdata`, and any directory whose name begins with `.` or `_`, are ignored by pattern expansion entirely. This is what lets a repository keep intentionally-uncompilable fixtures under `testdata/` without `go build ./...` ever tripping over them. ## The output rule that surprises people `go build` writes an executable only when it is given **exactly one main package**. Give it several packages — which `./...` almost always does — and it compiles everything and **discards the results**. The documented purpose of that mode is to serve as a check that the packages build. So `go build ./...` is an excellent, cheap "does the whole tree still compile" step and a completely ineffective way to produce artefacts. Engineers new to Go run it, see no error, look for binaries and find none. A non-main package behaves the same way for a different reason: there is nothing to link, so building it can only ever be a check. ## Getting the binaries you wanted There are two honest ways to turn a pattern into executables: - **`go install ./cmd/...`** builds every main package under `cmd/` and installs each into `$GOBIN` (or `$GOPATH/bin`), named after the last element of its package path. - **`go build -o bin/ ./cmd/...`** writes them into a directory of your choosing instead. `-o` accepts a directory, and each main package produces one file inside it. Passing a **single file name** with several main packages is rejected — the go command will not silently pick one or overwrite in a loop. For a single command, `go build -o bin/api ./cmd/api` remains the direct form. ## Where this shows up in real repositories - **CI compile gate:** `go build ./...` as a fast step that fails on a package nobody imports from a test — a package with no tests and no importers is otherwise never compiled by `go test ./...`. - **Check-only builds:** `go build -o /dev/null ./...` makes the discard explicit for readers who do not know the multi-package rule. - **Release step:** `go build -o dist/ ./cmd/...` to collect every command of a repository in one directory. - **Selective work:** `./internal/...` or `./cmd/...` when a full-tree build is slower than you want. ## Common misreadings - Believing `./...` includes dependencies. It does not; `all` is that pattern. - Believing `go build ./...` writes one executable per main package into the current directory. It writes nothing. - Believing `...` is a shell glob. It is interpreted by the go command, so quoting rarely matters and `./…`-style patterns work identically on every platform. A shell glob such as `./cmd/*` would expand to directories and behave differently. - Forgetting that a broken file in `testdata/` is invisible to the build, and then being confused about why an editor reports errors the build does not. ## Why interviewers ask It separates people who have run Go commands from people who have only read them. The pattern rules and the discard rule are exactly the two things that bite when you write a Makefile or a CI job for the first time, and being able to state both — plus the `-o <dir>` remedy — shows the candidate has built and shipped something rather than just run `go run .`.