Understanding ./... Package Patterns in Go Commands

./... is a Go package pattern, not a Unix shell pattern. It tells commands such as go test, go build, and go list to select the package in the current directory and packages in its subdirectories recursively. By the end, you will know how package patterns work, what directories are included or skipped, and which Go commands commonly use them.

Go commands often accept package patterns: arguments that identify one or more Go packages.

The pattern:

./...

means:

• .: start in the current directory.
• /...: include packages in that directory and recursively below it.

For example, from a module root with this layout:

myapp/
├── go.mod
├── main.go
├── api/
│   └── handler.go
├── internal/
│   └── config/
│       └── config.go
└── tools/
    └── helper.go

running this command:

go test ./...

asks Go to find and test all packages represented by the current directory and its eligible subdirectories.

This is not expanded by Bash, Zsh, or another Unix shell. The shell normally passes ./... as text to the go command, and the Go tool interprets it.

Package patterns matter because Go projects commonly contain several packages. A single recursive command lets you build or test the whole module instead of naming every package manually.

Think of ./... as telling Go:

“Start in the folder I am standing in, then visit every relevant Go package in the folders below it.”

The . is your current location on a map. The ... is a recursive search instruction.

It is similar in spirit to asking a file-search tool to search a directory tree, but it is more specific: Go is looking for packages, not simply every .go file.

Go package patterns are supplied after a command:

go <command> <package-pattern>

Common patterns include:

Example project:

shop/
├── go.mod
├── main.go
├── cart/
│   ├── cart.go
│   └── cart_test.go
└── price/
    ├── price.go
    └── price_test.go

From shop/, run:

go test ./...

Go finds the packages for:

• shop
• shop/cart
• shop/price

and runs each package's tests.

To target only the packages below cart, use:

go test ./cart/...

To target only the package in your current directory, without descending into subdirectories, use:

go test .

Suppose your module looks like this:

notes/
├── go.mod
├── main.go
├── format/
│   ├── format.go
│   └── format_test.go
└── store/
    ├── store.go
    └── store_test.go

You run:

go test ./...

What happens:

1. Your shell starts go and passes ./... to it. The shell does not turn it into a list of directories.
2. The Go tool sees ./... as a package pattern.
3. . tells Go to begin at notes/, the current directory.
4. ... tells Go to look recursively below that directory.
5. Go identifies packages in the root, format/, and store/.
6. Go compiles the selected packages and their required dependencies.
7. Go executes tests in packages that contain *_test.go files.

A useful way to inspect the exact package list before building or testing is:

go list ./...

This prints the package import paths selected by the pattern.

Developers use ./... when an operation should apply to an entire module or a major subtree.

• Run all tests locally

  go test ./...
  

• Run tests with the race detector

  go test -race ./...
  

• Build every package to catch compile errors

  go build ./...
  

• List module packages for scripts or CI diagnostics

  go list ./...
  

• Format all Go source files selected through package discovery

  gofmt -w $(go list -f '{{.Dir}}' ./... | xargs -n1 find -name '*.go' -type f)
  

  In practice, formatting is often handled by dedicated tools or editor integrations, but package discovery remains useful in automation.

• Limit work to one application area

  go test ./internal/...
  

  This tests packages only under internal/.

In real projects, ./... is especially common in CI because it catches failures outside the package currently being edited.

A typical verification sequence is:

go test ./...
go vet ./...
go build ./...

Developers also narrow the pattern to make commands faster while working:

go test ./service/payment/...

Inspect before acting

Use go list when you are unsure what a pattern selects:

go list ./...

This is helpful when a repository contains generated code, examples, commands, or multiple services.

Modern dependency workflow

The historical command from the question contains:

go get -d -v ./...

Older Go workflows used go get -d to download dependencies without installing packages. In module-based projects today, dependency management is usually handled with commands such as:

go mod tidy
go mod download
go test ./...

go test and go build automatically download required module dependencies when needed. The meaning of ./... itself remains the same: it selects packages recursively.

Assuming ./... is a shell glob

It is a Go package pattern, interpreted by the go tool.

# Go interprets ./..., not your shell.
go test ./...

Do not expect this to behave like a general-purpose Unix wildcard in commands unrelated to Go.

Using ... without the intended starting directory

These patterns have different scopes:

go test .          # current package only
go test ./...      # current package plus recursive subpackages
go test ./api/...  # packages under api/

Choose the narrowest pattern that matches your task.

Expecting every directory to become a package

A directory is only relevant if it represents a package Go can load. A plain folder with no applicable Go source files may not produce a package result.

Forgetting that some directory names are ignored

When using recursive ... patterns, directories beginning with . or _ are ignored. Vendor directories are also excluded from ... traversal unless explicitly requested.

For example, this directory is not discovered by go test ./...:

_internal-experiments/

because its name begins with _.

Running from the wrong directory

./... is relative to your current shell directory. If you run it from a parent directory or a nested directory, it can select a different set of packages than expected.

Check where you are:

pwd
go list ./...

Treating go build ./... as a binary installer

go build ./... checks and builds selected packages, but it is not the usual command for installing an application binary into GOBIN. For that, use go install with the appropriate package path.

./... is also different from shell wildcards:

The important distinction is that Go package patterns work with Go's understanding of modules, packages, build rules, and import paths.

.             current Go package
./...         current package and all recursive subpackages
./dir/...     all packages below dir/

Common commands:

go list ./...       # show selected packages
go test ./...       # test selected packages
go build ./...      # build/check selected packages
go vet ./...        # analyze selected packages

Rules to remember:

• ./... is interpreted by the Go tool, not the Unix shell.
• It is relative to the directory where you run the command.
• It selects packages, not every file or every directory.
• Directories beginning with . or _ are ignored during recursive matching.
• Vendor directories are excluded from ... traversal unless explicitly requested.
• Use go list ./... to see exactly what will be selected.

What does ./... mean in Go?

It means the package in the current directory (.) plus Go packages in its subdirectories recursively (...).

Is ./... a Bash or Unix wildcard?

No. It is a package pattern understood by Go commands such as go test, go build, and go list.

Does go test ./... test the current package too?

Yes. A trailing /... pattern includes the package in the starting directory as well as packages below it.

What is the difference between go test . and go test ./...?

go test . tests only the current package. go test ./... tests that package and recursively selected subpackages.

How can I see which packages ./... matches?

Run:

go list ./...

Does ./... include hidden directories?

No. During recursive matching, directories whose names begin with . or _ are ignored. Vendor directories are also excluded unless explicitly named.

Does go build ./... install binaries?

No. It builds the selected packages to verify they compile. Use go install when you want to install an executable to your Go binary directory.

Should I still use go get -d ./... to download dependencies?

For modern module-based projects, prefer go mod download, go mod tidy, or let go test and go build obtain required dependencies automatically.

• Go modules — Modules define dependency boundaries and commonly provide the root from which ./... is run.
• Go packages — Package patterns select packages rather than individual source files.
• go test — The most frequent command used with recursive package patterns.
• go build — Uses the same patterns to compile multiple packages.
• go list — Shows the packages that a pattern resolves to.
• Import paths — Named package patterns are based on import paths rather than relative directories.
• Go workspaces — Workspaces can affect how local modules are resolved when Go loads packages.
• Shell globbing — Useful for understanding why ./... is not a normal filesystem wildcard.