// the take
go-jsonstruct generates a Go struct definition from a set of sample JSON or YAML objects, inferring the most specific type that fits every sample rather than just the first one. It's for developers dealing with loosely-typed JSON from a REST API, a JSON column in a database, or a pile of YAML config files who don't want to hand-write or guess at struct tags.
Taking multiple samples instead of one is the actual differentiator over tools like json-to-go: optional fields get omitempty, fields that are sometimes null and sometimes a value fall back to a pointer without omitempty so the two cases stay distinguishable, and mixed numeric types widen to float64 only when needed. Output is deterministic based solely on structure, so it's safe to wire into a build step to catch schema drift. It also handles the fiddly real-world stuff: capitalizing ID/URL/HTTP per Go convention, camelCase/kebab-case/snake_case field name conversion, and working around the encoding/json property-with-spaces bug.
It's a heuristic over whatever samples you feed it, not a schema — a field that's a string in every sample but occasionally an int in production will generate a struct that silently breaks at unmarshal time weeks later, not at generation time. There's no real union type support beyond collapsing to `any`, so API responses with genuine polymorphism need manual fixups to the generated code anyway. The generated struct has no built-in path back to regeneration when the upstream shape changes, so teams have to remember to re-run it; nothing flags drift automatically. It's effectively a single-maintainer project (twpayne), so bus-factor risk is real if you're depending on it as a long-term build step rather than a one-off codegen pass.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →