In Go, ./... is a wildcard pattern used by Go commands (like go test, go fmt, go list) to recursively match all Go packages starting from the current directory — including nested subdirectories.
in go, `./...` is a wildcard pattern used by go commands (like `go test`, `go fmt`, `go list`) to recursively match all go packages starting from the current directory — including nested subdirectories.
The ./... syntax is Go’s built-in package path pattern — not shell globbing, and not interpreted by your terminal. Instead, it’s parsed directly by the Go toolchain. Here's how it works:
-
.refers to the current directory (i.e., the root of the module or the working directory containinggo.mod, if any). -
...is a recursive wildcard: it matches zero or more directory elements, meaning it includes:- The current directory (
.), - All immediate subdirectories,
- And all deeper nested directories — as long as they contain at least one
.gofile and form a valid Go package (i.e., have apackagedeclaration and aren’t excluded by build constraints).
- The current directory (
✅ Example:
Running
<code class="bash">go test ./...</code>
executes tests in every package under the current directory tree — ideal for testing an entire multi-package module at once.
⚠️ Important notes:
-
./...does not include vendor directories by default (since Go 1.14+,vendoris ignored unless-mod=vendoris set). - It skips directories with names starting with
.(e.g.,.git,.vscode) or_(e.g.,_examples) — per Go’s standard exclusion rules. - It respects build tags (e.g.,
//go:build !ignore) — packages excluded by constraints won’t be matched. - Unlike shell
**,...is Go-specific:go fmt ./...works even on Windows (no shell expansion needed), and behaves consistently across platforms.
? Pro tip: To preview which packages will be affected before running a command, use:
<code class="bash">go list ./...</code>
This prints all matched package import paths — great for debugging or CI scripting.
In summary: ./... is Go’s concise, portable, and semantically aware way to say “all packages in this module, recursively”. Mastering it unlocks efficient, scalable development workflows — especially in monorepos or large codebases with multiple internal packages.
