pact-go
pact-go copied to clipboard
feat: add support to MatchV2 structs generated by proto-gen-go
Allows for reuse of structs generated by the client code for reuse with protobuf or json. The protobuf portion of the struct definition was not compatible with the MatchV2 due to some field types not supported, eg func. And in some cases the json information is only an attribute of protobuf tag.
This enhancement has a strategy of
- json tag
- protobuf tag (parse json attribute)
- skips field
The skip may be a breaking change, but as far as I can tell, any compliant type w/o a json tag would create an empty key in the struct, so technically it makes this more clear.
🤞
Coverage: ?%. Remained the same when pulling 0eb0a270239d745c5275fc05233707960261e94b on hborham:feature/proto-gen-go into 5eda04090104e8fc419cf088863edbe2e53f090d on pact-foundation:2.x.x.
Coverage: 37.589% (+0.2%) from 37.385% when pulling 0eb0a270239d745c5275fc05233707960261e94b on hborham:feature/proto-gen-go into 5eda04090104e8fc419cf088863edbe2e53f090d on pact-foundation:2.x.x.
fyi - this is more of a wip/prototype at this point as i'm trying to get this to work with protojson structs.
Thanks for this Haz.
Let's have a think about if it makes sense to bake any protobuf specific items into the main package, of it is best left as an extension in a separate package. It feels like a slippery slope for Pact Go to "know" about all kinds of other protocols, which I think is not idealy.
yep - i agree. i tried to rework this in a different way. i'm curious as how to do the extension.
feel free to tell me what you'd like and i can get it done if you're interested in supporting this extension point
the use case on my end is we have client generated code from proto files. while writing the pact definitions i cannot reuse any of the pb.go structs and duplicate a lot of unnecessary structure. so i'd like to add an extension to support my case and only need to tap into the #match swtich case reflect.Struct:
the main parts of a protojson struct to consider:
- some fields do not contain a protobuf or json tags so skipping these is ideal.
- enums are typed as int in the protomessage format, but mapped to string for json.
@hborham do you want to possibly mark this PR as a draft?