[#477] add WithProtoJSONOptions() expose protojson marshalling options

[natemurthy]

r? @akshayjshah

I'd like to merge this fork from @greg-montoux / @xxgreg into the main repository. I'm experiencing the same challenges customizing my protojson marshalling/unmarshalling options as proposed in: Issue https://github.com/bufbuild/connect-go/issues/477

In my specific case, I have a large body of legacy JSON APIs maintained with lower_snake_case and the default camelCase marshaling is throwing some consistency curveballs my way.

I think this option method should be available to everyone as soon as convenience allows. My alternative is to maintain a fork this repository.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[xxgreg]

(Replying from my other GH account)

Another API worth considering is to export a constructor for protoJSONCodec and allow setting the options there.

This would look something like:

mopts := protojson.MarshalOptions{
...
}
uopts := protojson.UnMarshalOptions{
...
}
cn.NewClient(..., cn.WithCodec(cn.NewProtoJSONCodec(mopts, upots))

It looks like the workaround in the meantime is to fork the protoJSONCodec struct, which isn't too bad either.

[akshayjshah]

In general, I'm reluctant to expose APIs from connect-go that don't require access to significant chunks of the package internals. Over time, this policy keeps the surface area of connect-go as small and approachable as possible.

The protojson codec is so small that I don't think the proposed API expansion carries its weight. It's relatively easy, and just as functional, to provide this configurability from a separate package that replicates the JSON marshaling logic. I've done just that, so you can use go.akshayshah.org/connectproto today. (Please do keep in mind that this is a small personal repo rather than an official Buf project!)

We're sorting out the best way to make third-party packages like these more discoverable, but hopefully this unblocks you in the short term. I'll leave this PR open for a bit in case there's more discussion, but I don't intend to merge it.

[akshayjshah]

See above.

[natemurthy]

I ended up going with @akshayjshah's suggestion, thanks everyone!