Migration from gogen

Moving a Go project from the deprecated github.com/tecnickcom/gogen module path to github.com/tecnickcom/nurago

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.mod and go.sum, which go mod tidy rewrites for you.
  • Generated mocks (*mock_test.go), which carry the import path of the interface they mock. Regenerate them with go generate ./... if your project generates mocks.
  • Tooling and CI configuration: .golangci.yml exclusion rules, Makefile variables, 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/