protobuf icon indicating copy to clipboard operation
protobuf copied to clipboard

MutateHook for protoc-gen-go

Open gsingh-ds opened this issue 2 years ago • 6 comments

Hello There,

I was looking at the issue #52 . I want to add custom tag to generated struct's. I have written my custom plugin. Seems like there is no way to have Mutate hook before the *.pb.go is rendered. Only way possible is to overwrite the file after generated.

My questions: Is there way to add support of plugins to add custom tags ? like https://gqlgen.com/recipes/modelgen-hook/

gsingh-ds avatar Mar 01 '22 19:03 gsingh-ds

I'm afraid there is not. See also: https://developers.google.com/protocol-buffers/docs/reference/go/faq#custom-code

Can I customize the code generated by protoc-gen-go?

In general, no. Protocol buffers are intended to be a language-agnostic data interchange format, and implementation-specific customizations run counter to that intent.

neild avatar Mar 01 '22 19:03 neild

Hello @neild , Thank you for the quick response. Is there a specific reason why this is not supported? Is there anything you can recommend? to solve this issue.

gsingh-ds avatar Mar 01 '22 19:03 gsingh-ds

We can use the plugin like https://github.com/srikrsna/protoc-gen-gotag to make custom tag, but the plugin must run after the protoc-gen-go. I suggest that protoc-gen-go support the sub-plugin, for example:

protoc --go_out="plugin=gotag:." api.proto

defool avatar May 25 '22 01:05 defool

This has been variously discussed before, but the decision usually settles on, “we do not think this is a feature we can or should add.” Unfortunately, this package has a need to stick strictly to the protobuf standards, which by design targets multiple languages, and needs to ensure maximum compatibility.

We have already been bit before by adding json tags, because in Go doing so was so easy to do. But now that protobuf has a standard JSON mapping, those JSON tags are now non-compliant, and the standard library encoding/json cannot be retrofitted to make it compliant. However, because people have been relying on the json tags, we cannot just remove them, even though they were a mistake.

Because of this history, we’re quite reluctant to add anything unilaterally, and the protobuf project as a whole frowns upon adding language-specific features, because as mentioned, it needs to be language-agnostic. There have been people presenting tools to perform this ask, but the official golang protobuf module is unlikely to ever take up things that have not been agreed upon by the wider protobuf standard.

puellanivis avatar Jun 10 '22 11:06 puellanivis

Thanks for your serious answer, I think protobuf should really be a project independent of the programming language. But in go language, some go tags can be very helpful for development, such as parameter binding/validation, database, etc.

I think protoc-gen-go itself should not provide the ability to customize the code, but it should leave some extensibility for developers to modify the generated code.

For example, I think the InsertionPoint feature in the protoc plugin might offer some possibilities for extensibility. It would be very helpful if protoc-gen-go could reserve some insertion points for the generated code.

type CodeGeneratorResponse_File struct {
...
InsertionPoint *string `protobuf:"bytes,2,opt,name=insertion_point,json=insertionPoint" json:"insertion_point,omitempty"`
...
}

By the way, protoc's insertion point is somewhat inconvenient to use. I think when the code we want to insert is generated, the token that defines the insertion point should be automatically removed, not kept in the generated code.

Thanks again for your answer

FGYFFFF avatar Jun 11 '22 14:06 FGYFFFF

There are already extensive standard-library tools to parse Go code, so that tools can be written to intelligently modify source code rather than doing something like an inevitably error-prone sed script.

puellanivis avatar Jun 11 '22 18:06 puellanivis