Proposal
Many Go codebases already use struct tags named validate:"..." (the convention from go-playground/validator). Migrating such a codebase to Checker currently means rewriting every struct tag.
In checker.go, where the tag config is read:
config := field.Tag.Get(checkerTag) // checkerTag == "checkers"
add a fallback: if checkers is absent/empty on a field, fall back to reading the validate tag instead. This doesn't require Checker to understand validate's syntax — it's a one-line lookup fallback, not a compatibility shim for validator's tag semantics — but it substantially lowers the switching cost for teams already using the validate:"required,email"-style tag name with checker syntax they've written for Checker.
Document the fallback clearly in the README so it's not confused with actual go-playground/validator tag-syntax compatibility (it isn't that — only the tag name is a fallback, not the tag contents).
100% test coverage; CHANGELOG.md entry.
Proposal
Many Go codebases already use struct tags named
validate:"..."(the convention fromgo-playground/validator). Migrating such a codebase to Checker currently means rewriting every struct tag.In
checker.go, where the tag config is read:add a fallback: if
checkersis absent/empty on a field, fall back to reading thevalidatetag instead. This doesn't require Checker to understandvalidate's syntax — it's a one-line lookup fallback, not a compatibility shim forvalidator's tag semantics — but it substantially lowers the switching cost for teams already using thevalidate:"required,email"-style tag name with checker syntax they've written for Checker.Document the fallback clearly in the README so it's not confused with actual
go-playground/validatortag-syntax compatibility (it isn't that — only the tag name is a fallback, not the tag contents).100% test coverage;
CHANGELOG.mdentry.