Resolve import cycle when enum is in same Go package

[TravelThePath]

Summary

Fix self-import cycle in generated *.pb.validate.go files when proto files within the same Go package reference each other's enum types.

Problem

When proto file A imports proto file B, and both files share the same go_package but have different proto package names, the generated A.pb.validate.go file imports its own Go package, creating an import cycle that breaks go build.

Example:

• entity_admin.proto (proto package jasper.admin.entity.v0, go_package admin/pb)
• document_admin.proto (proto package jasper.admin.document.v0, go_package admin/pb)

When entity_admin.proto uses DocumentVisibility (defined in document_admin.proto) in a field with validation rules, the generated code produces:

package pb  // file is IN admin/pb

import (
    pb "github.com/example/service/admin/pb"  // imports ITSELF → cycle
)

var (
    _ = pb.DocumentVisibility(0)  // dead assignment requiring the self-import
)

This pattern is common in codebases that vendor proto files from other services and set go_package to the local service path.

Root Cause

The externalEnums function in templates/goshared/register.go determines whether an enum needs an external import by comparing proto package names:

if en != nil && en.File().Package().ProtoName() != msg.File().Package().ProtoName() {

This is incorrect because two proto files can have different proto package names but share the same go_package option, placing them in the same Go package. The comparison should use Go import paths instead.

This regression was introduced when the original dual check (ProtoName + PackageName) was simplified to only ProtoName during the enum package collision fix.

Fix

Changed the comparison from proto package name to Go import path using fns.ImportPath(), which is the same API that protoc-gen-star's own importableTypeName function (in type_name.go:38) uses for the identical purpose:

fileImportPath := fns.ImportPath(file)

if en != nil && fns.ImportPath(en) != fileImportPath {

Testing

• Verified against 6 Go microservices that exhibited this bug — all now build cleanly
• go build ./... passes on the protoc-gen-validate repo itself
• go vet ./... passes

Related Issues

• ensure the imports are used is broken #585 — ensure the imports are used is broken
• Golang: importing enums into package names with same ending component generates compiler errors #672 — Golang: importing enums into package names with same ending component generates compiler errors
• Package import conflict in generated Go code with multiple imported proto packages #305 — Package import conflict in generated Go code with multiple imported proto packages

🤖 Generated with Claude Code

[CLAassistant]

All committers have signed the CLA.

[rodaine]

Thanks for the patch!