Lectures

Let’s break down Go’s module system in practice: what a module and a package are, how to choose a module path, create a project with go mod init, read the key directives in go.mod ( module, go, require), import your own packages using the module prefix, and why go.sum is needed for reproducibility and dependency integrity verification.

We will break down two key commands of Go's module system: go get (selecting and pinning module versions) and go mod tidy (synchronizing dependencies based on actual imports). We will understand how go.mod/ go.sum work, where the // indirect markers come from, how a package import differs from a module path, and what a dependency lifecycle looks like using the todoapp project as an example.

We break down the replace directive in go.mod: why you need it for locally verifying fixes without a release, how the two replacement forms work (to a local path and to another module path/version), how to wire in a neighboring module via replace, and why this easily turns into “works only on my machine” (CI, reproducibility, limitations in some commands). At the end: a checklist for when replace is appropriate, and common mistakes.

We break down what vendor/ is in Go and how it affects builds: where the go tool gets source code for imports, how vendoring differs from the module cache and the replace directive, how the directory is created via go mod vendor, what is stored in modules.txt, when vendor/ saves you (offline / isolated environment / audit), when it turns into dead weight, and which mistakes teams most often make.

We break down workspace mode in Go: why the go.work file exists, how the use directive “glues” multiple modules together for local development, why this is better than temporary replace directives in go.mod, how to create and extend a workspace with go work init and go work use, how to diagnose whether the mode is enabled via GOWORK, and when it makes sense to run go work sync.