uber-go
Adopt cmp.Diff for showing unmatched arguments
@r-hang @sywhang @JacobOaks, what's needed to get this PR into shape for approval?
Hey @SpencerC, thanks for the contribution and sorry for the delay.
While I understand that the go-cmp library has lots of users and powerful features, I think that having this mocking library expose another repository's types as part of its public interface could make it harder to maintain as we're tightly coupled with go-cmp. Is there a way for this library to own all of its exported types?
Hey! Here are the options I see for avoiding exporting go-cmp arguments:
- Export wrapper type analogs for the 8
cmp.Options, and convert them to go-cmp types under the hood. - Vendor-in or rewrite the diff computing functionality from the current version of go-cmp and maintain it yourself going forward.
Can you think of any other options? I'm happy to do either of those if you think they're really preferable to exporting go-cmp types.
I definitely agree with you in principle on maintaining minimal reliance on exported external deps. I feel like in the case of go-cmp though it's so established and so stable that it might as well be treated like a built-in type for the purposes of maintaining a library (like the golang.org/x/... packages used elsewhere in this library). Likewise, if users pose questions about how to properly configure rich diffs you can just say "refer to the go-cmp docs, we just pass those options through".
Hey @SpencerC, I'm personally open to using wrapper type analogs for go-cmp options, I think that's more favorable than vendoring go-cmp in.
Instead of initially adding 8 options, I think it makes sense to make go-cmp's drive diffing presentation for unmatched arguments and then port over the options individually as needed. What do you think?
@r-hang, sorry just realized I didn't reply. That sounds fine to me, will just take some time for me to get back to this. Thanks!