Allow stripping / adding back enum prefixes when encoding/decoding JSON

[dorner]

What language does this apply to?

Proto3 encoding and decoding to JSON. Looked at this with Go, but it applies across the board.

Describe the problem you are trying to solve.

This was originally posted in golang/protobuf#1598 .

The accepted approach to avoid namespace collisions with Protobuf enums is to prefix them, e.g.

enum PurchaseMethod {
  PURCHASE_METHOD_UNSPECIFIED = 0;
  PURCHASE_METHOD_ONLINE = 1;
  PURCHASE_METHOD_IN_STORE = 2;
}

Tools like buf will actually lint this and not allow you to check in a proto file where this doesn't happen.

When encoding to JSON, this results in a "stutter" like so:

{ purchase_method: "PURCHASE_METHOD_IN_STORE" }

There is an existing discussion here regarding fixing the Go code generation, which might ease the namespace issues. But that discussion has been ongoing since 2018 without a resolution.

Describe the solution you'd like

I was hoping to at least be able to make protojson and other JSON encoders "smarter" in this case to give it an option to remove the stuttering. This would involve an additional option which could remove the shared prefix on encoding, and add it back on decoding, to allow the generated JSON to be slimmer and easier to read.

Describe alternatives you've considered

Really the only way to "fix this" fix this would be to relax the namespacing requirement entirely and allow for generation of non-prefixed enums. I imagine this would be quite hairy to enable. Limiting this to the JSON generation would give us at least some relief.

Additional context

This is a sample PR for how this would work on the Go side (I tested it and it does work - obviously we wouldn't include the dependency I added there for the sake of getting it working faster).

First issue here, so please let me know if anything needs more info or a different approach to spark discussion.

[EraYaN]

The C# generator already removes the type name from the Enum values too. It would be great if the behaviour was consistent. And shorter names are always good, especially in languages that require you to include the enum everytime anyway. SomeEnum.SOME_ENUM_VALUE1 just looks worse than SomeEnum.VALUE1.