3rd Party Packages in Go

Use community modules: add dependencies with `go get`, understand `go.mod` / `go.sum`, direct vs indirect deps, versioning, the module proxy and cache, private modules, vendoring, and tooling.

Third-Party Modules vs Standard Library

The standard library ships with Go (`fmt`, `net/http`, `context`, etc.). Third-party (external) modules are published on sites like GitHub and fetched through the module proxy (`proxy.golang.org` by default). You add them with `go get`, import them by module path, and they appear in your `go.mod` file as dependencies.

1. Standard Library vs External Modules

Import paths and where code comes from.

Adding and Updating Dependencies

`go get` records a module in `go.mod` and downloads it into the module cache. You can request a specific semantic version (`@v1.2.3`), `latest`, or upgrade with `-u`. After changing dependencies, run `go mod tidy` so `go.mod` and `go.sum` match your imports.

1. go get for Third-Party Modules

Add, upgrade, and pin versions.

go.mod, go.sum, and Trust

`go.mod` lists module paths and versions your project needs. `go.sum` stores cryptographic hashes of the exact module contents so builds are verified and reproducible across machines. Semantic versioning (v1, v2, …) helps you understand compatibility; major version bumps may require import path changes (for example a `/v2` suffix).

1. Commit go.mod and go.sum

Team builds and CI rely on them.

2. Choosing Third-Party Packages

Reduce risk before you depend on a module.

go.mod Anatomy

Like `package.json` in Node, `go.mod` is the manifest for your module. The `require` block lists dependencies; lines marked `// indirect` are not imported directly by your code but are needed by other modules. You can use `replace` to redirect a module path (for local forks or patches) and `exclude` to block a bad version.

1. Direct vs Indirect Dependencies

What // indirect means in go.mod.

2. replace and exclude

Override module sources or block versions.

Versioning and Import Paths

Go modules use **semantic versioning** tags (`v1.2.3`). For **v0** modules, breaking changes are allowed. From **v1** onward, compatible releases keep the same major version. A **v2 or higher** module must use a **major version suffix** in the import path (e.g. `example.com/foo/v2`), which is different from npm where the package name often stays the same.

1. Tags and Pseudo-Versions

Released versions and commits without tags.

2. Major Version v2+

Import path must include /vN.

Proxy, Cache, and Private Modules

By default, `GOPROXY` points at `https://proxy.golang.org`, which caches public modules. Downloaded zip files live in the **module cache** (`GOMODCACHE`, often under `~/go/pkg/mod`). Private or company modules should bypass the public proxy: set **`GOPRIVATE`** (and often `GONOSUMDB`) so authentication works and checksums are not sent to the public sum database.

1. Module Cache and GOPROXY

Where modules live on disk.

2. GOPRIVATE and GONOSUMDB

Private modules and checksum database.

Vendoring, Workspaces, and Automation

`go mod vendor` copies dependencies into a `vendor/` folder for reproducible or air-gapped builds—similar in spirit to checking in `node_modules` for deployment, but only third-party code. **Workspaces** (`go.work`) let multiple modules in one tree replace each other during development. **`go generate`** runs code generators before build, similar to npm `prebuild` scripts when combined with your workflow.

1. go mod vendor

Vendor directory for offline or policy builds.

2. Multi-Module Workspaces

go.work for local development across modules.

3. go generate

Run generators (unlike npm scripts, explicit step).