What does the module path mean?

The module path is the canonical import prefix for your packages and is usually your repository URL, like github.com/your-org/your-app. Other code imports your packages by appending the subdirectory to this path, so it must match where the module is hosted.

What is the go directive for?

The go directive declares the minimum Go language version your module targets, such as go 1.23. The toolchain uses it to enable or restrict language features and to decide which toolchain to download, so set it to the version you actually build with.

Why run go mod tidy after generating go.mod?

This builder lists your direct dependencies, but real builds also pull transitive ones. go mod tidy scans your imports, adds any missing requires, removes unused ones and writes go.sum with cryptographic checksums so every build verifies the exact module contents.

What is go.sum and do I need it?

go.sum records the expected hash of every module version your build uses, direct and transitive. Go verifies downloads against it to prevent tampering, so you should commit go.sum alongside go.mod. It is generated automatically by go mod tidy or go build.

How does Go version a dependency?

Go modules use semantic import versioning. Tags look like v1.10.0, and a major version of 2 or higher appends a /vN suffix to the import path, such as github.com/go-chi/chi/v5. The version in the require line pins exactly which tagged release is used.

What is the go.mod Builder?

Create a go.mod with module path, go directive and a require block for common dependencies — chi or gin routers, pgx, sqlx, zerolog, testify, godotenv and uuid — with real semver tags. It runs free in your browser on Gera Tools, with nothing uploaded.

go.mod Builder — Gera Tools

Name: go.mod Builder
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

The go.mod Builder creates the manifest that defines a Go module: its import path, the Go language version it targets and a require block of dependencies. Pick the common libraries your service needs and the tool emits valid module paths with real semver tags.

How it works

A go.mod file starts with a module line that sets the canonical import prefix — usually your repository URL — followed by a go directive declaring the minimum language version. The require block lists each dependency as a module path plus a version tag. The tool renders a single inline require for one dependency or a parenthesised block for several, sorting paths so the output is stable.

Go uses semantic import versioning: tags look like v5.1.0, and any major version of 2 or higher carries a /vN suffix in the import path itself, which is why chi appears as github.com/go-chi/chi/v5. Each toggle maps to a real, widely used module at a recent stable tag.

What the generated file contains

A typical output for a web service with a database layer looks like this:

module github.com/your-org/your-app

go 1.23

require (
    github.com/go-chi/chi/v5 v5.1.0
    github.com/jackc/pgx/v5  v5.6.0
    github.com/rs/zerolog    v1.33.0
    github.com/stretchr/testify v1.9.0
)

Each line names a dependency at a precise tagged release. Go’s module system uses these exact versions; it will not silently upgrade them, which is why pinning to tagged releases is the correct practice rather than using latest.

The dependencies available in this builder

chi (github.com/go-chi/chi/v5) — a lightweight, idiomatic HTTP router with middleware support; favoured for microservices because it uses the standard net/http handler interface without wrapping it
gin (github.com/gin-gonic/gin) — a higher-level web framework with built-in binding, validation and rendering; faster to prototype with, heavier than chi
pgx (github.com/jackc/pgx/v5) — the recommended PostgreSQL driver and connection pool for Go; supports prepared statements, binary protocol and pgxpool for concurrency
sqlx (github.com/jmoiron/sqlx) — extends database/sql with struct scanning and named queries; pairs with any SQL driver including pgx’s stdlib adapter
zerolog (github.com/rs/zerolog) — zero-allocation structured JSON logger; outputs fields as a JSON object per line, easily ingested by Datadog, CloudWatch, or similar
testify (github.com/stretchr/testify) — the de facto assertion library for Go tests; provides assert, require, and mock sub-packages
godotenv (github.com/joho/godotenv) — loads .env files into environment variables for local development
uuid (github.com/google/uuid) — generates and parses RFC 4122 UUIDs (v4 random is the usual choice for database primary keys)

Next steps

After saving go.mod, let the Go toolchain finish the job:

go mod tidy   # add transitive deps, drop unused ones, write go.sum
go build ./...

Tips and notes

Always commit go.sum next to go.mod — it stores verified checksums for every module so builds are tamper-resistant and reproducible. Set the go directive to the version you actually build and test with, since it controls which language features are available. If you later need a dependency this tool does not list, just go get module@version and go mod tidy will fold it in.

If your module is internal and not hosted on a public VCS, you can still use any import path as the module name (for example mycompany.internal/payments). The module directive is just a string identifier; it does not have to be a real URL for private modules.