Table of contents
This project was previously named gogen. Same library, same packages, new name.
The github.com/tecnickcom/gogen module path is deprecated. A build pinned to v1.145.0 or earlier keeps working, because those versions still declare module github.com/tecnickcom/gogen in their go.mod. From v1.146.0 onwards the tags declare the new module path, so the old import path no longer resolves at all:
go: github.com/tecnickcom/gogen@latest (v1.154.3) requires
github.com/tecnickcom/gogen@v1.154.3: parsing go.mod:
module declares its path as: github.com/tecnickcom/nurago
but was required as: github.com/tecnickcom/gogen
An old pin therefore keeps building until you try to update it, at which point the migration below is the only way forward.
The Migration
Three commands, from the root of your project:
go get github.com/tecnickcom/nurago@latest
find . -name '*.go' -exec sed -i 's|github.com/tecnickcom/gogen|github.com/tecnickcom/nurago|g' {} +
go mod tidy
On macOS, sed -i requires an argument: use sed -i '' in the second command.
The package layout under pkg/, the exported symbols, and the behaviour are unchanged, so no call site needs editing beyond the import path.
Check the Rest of the Tree
The find above covers Go source only. The old path can also appear in:
go.modandgo.sum, whichgo mod tidyrewrites for you.- Generated mocks (
*mock_test.go), which carry the import path of the interface they mock. Regenerate them withgo generate ./...if your project generates mocks. - Tooling and CI configuration:
.golangci.ymlexclusion rules,Makefilevariables, Dockerfiles, and vendoring directories. - Documentation, READMEs, and code comments.
A single grep confirms the tree is clean:
grep -rn 'tecnickcom/gogen' . --exclude-dir=.git
Verify
go build ./...
go test ./...
Then confirm the old module is no longer in the build graph:
go mod why -m github.com/tecnickcom/gogen
An answer of “module … is not needed” means the migration is complete. If it is still needed, something in your dependency tree imports it: go mod graph | grep gogen shows which module.
Mixed Builds
Both module paths can coexist in one build while the migration is under way, as long as the gogen side stays pinned at v1.145.0 or earlier, since the Go toolchain then sees two distinct modules. Their types are distinct too, so a gogen/pkg/metrics.Client will not satisfy a parameter typed as nurago/pkg/metrics.Client, and the binary carries both copies. This is a state to pass through, not to stop in: the gogen side can no longer be updated.
For AI Coding Assistants
An assistant trained before the rename will suggest github.com/tecnickcom/gogen imports, which is the most common wrong answer about this library. /docs/ai-assistants/ has the rules to pin against it.
Previous: /docs/testing/
Overview: /docs/
Next: /docs/development/