Closed johnfishbein closed 2 years ago
Hi @johnfishbein - apologies for the delayed response. It is certainly possible to collect the Enum options, so long as the parser knows how to do so. I believe it should, but you might want to check the API in https://github.com/emicklei/proto. If we need to bump the dependency version to get this support, I would happily accept a PR for that in addition to the feature you need.
Currently, I don't have bandwidth to add support for this but the code should be relatively straightforward, given other option
type data is collected in other data types.
If you are interested in giving the implementation a shot, I can point you in the right direction!
Closed in #138
Hi, Recently I've been working on creating a custom protolock plugin specific to my codebase. My plugin relies on a few custom options I've defined. Using protolock, custom options defined at the file level and message level are parsed by the tool into the Protolock struct, but options defined inside enums are not parsed by the tool.
The Entry struct contains the Options field which receives all of the file level options after parsing.
Similarly, the Message struct also contains an Options field which the message level options are parsed into.
However, Enum options are ignored during parse. The Enum struct does not include an Options field, but it does include the AllowAlias option which is one of many possible enum level options.
Is there a reason for this decision to not include the Options field for enums? If not, would it be difficult/possible to include enum level options?
An example of what I'm trying to do is:
Thank you!