protobuf.js
protobuf.js copied to clipboard
feat: honor json_name option
Honor the json_name option. This is useful when a .proto file is compiled for multiple languages, to conform to whatever random casing rules were chosen for the project:
- The .proto convention is to use lower_snake_case for field names, and UPPER_SNAKE_CASE for enum names
- C++ (via protoc) simply uses lower_snake_case for field names
- C# (via protobuf-net) uses PascalCase for both field and enum names, and has options for customizing the names
- JavaScript (via protobuf.js) uses camelCase for field names, and the json_name attribute can now be used to customize the name
Example:
message NetworkAdapter {
string get_ip_address = 1 [json_name = "getIPAddress", (.protobuf_net.fieldopt).name ="GetIPAddress"];
}
Default names without the options:
- C++: get_ip_address (unchanged)
- C#: GetIpAddress
- JS: getIpAddress
Fixes #992, fixes #1245, fixes #1775
Can we prioritize this review? We need it as well.
Will this change also use json_name for files generated statically?
Any update on this? Would really like to see this land.
it seems we have a solution here for this https://github.com/protobufjs/protobuf.js/issues/564#issuecomment-280923387
The linked comment is not exactly a solution as it doesn't respect the explicitly defined json_name.
Is there any way I could help this PR move forward and get merged?
I just did a quick test against v7.2.5
and it seems to be working. I really need this functionality and I would like to to avoid having to maintain my own fork.
+1 to releasing it as a major version. This change will definitely break my current use case.
Can this be behind a build flag/option?
Alternatively this could be a runtime option which is off by default.
Runtime option might not work with folks like us using the statically generated files.
I think it can technically go to IParseOptions
(right near the keepCase
) and to the CLI flag of pbjs
for static proto generation. That way we can make it false by default and avoid making a semver major version. Not sure if @michaelbgreen has time to implement it that way though :) (I might have but later this month).
I am happy to see that this is getting traction, but sorry, I no longer have time to contribute to this.