We're building a forum app in Go for our Zone01 Kisumu cohort — five of us, split by feature: auth, posts, comments, filters, and me leading the core/integration side. Two weeks in, everything was compiling fine. Then one morning I pulled the latest code and the whole project refused to build.

The error looked something like this:

internal/posts/categories.go:6:2: package forum/internal/models is not in std

"Not in std"? My package isn't in the standard library. Weird flex, Go, but okay — what actually happened?

The setup

Here's the thing about Go modules that I hadn't really internalized until this bit me: the line at the top of go.mod

go
module github.com/kahenda/forum

isn't just a label. It's the namespace your entire project lives inside. Every internal import — internal/models, internal/auth, whatever — has to be spelled out as github.com/kahenda/forum/internal/models, because that prefix is literally derived from that one line.

Somewhere along the way, a teammate's branch had a go.mod that said module forum instead — probably from running go mod init fresh without checking what was already there. When that got merged, our shared go.mod briefly had the wrong module name. Nobody noticed immediately, because that specific person's own code still compiled — they'd written their imports against the wrong name too, so it was internally consistent for them.

The explosion happened for everyone else, because our code was written against the correct name, and now the correct name didn't exist anymore.

Why the error message was so confusing

package forum/internal/models is not in std doesn't sound like "your go.mod changed." It sounds like Go is looking for your package in its own standard library folder — which, technically, it is! Once the module name changes, Go has no idea forum/internal/models is your code. It just goes looking for it in /usr/lib/go/src/forum/..., finds nothing, and reports exactly that.

If I hadn't already known what module in go.mod actually controls, I'd have spent an hour convinced my Go installation was broken.

The fix

Two-part fix, and both parts matter:

Restore the correct module line:
go
module github.com/kahenda/forum
Fix every file that had been written against the wrong prefix:
go
// before
import "forum/internal/models"

// after
import "github.com/kahenda/forum/internal/models"

That second part is the annoying one — it's not a global find-and-replace across the whole codebase, just whichever files got written during the window when go.mod was wrong. We caught them one build error at a time, which is tedious but at least Go tells you exactly which file and line.

What I'd tell past-me

Treat go.mod like you'd treat a database schema in a team project — something one person owns and everyone else pulls, never something anyone regenerates locally without checking first. It's such a small file that it's easy to forget it's load-bearing for literally every import in the project.

Anyone else had a one-line config change cascade into a dozen confusing error messages? What was yours?