Camelcase is lost (Javascript protoc) #17
Comments
|
any updates on this? facing same issue. It would be nightmare to edit fieldnames when dealing with large number of proto messages! |
|
Having the same problem, just came here to gently bump the thread. :-) Additional testing also revealed that if I load the proto files directly with grpc-loader[1], then the dynamically generated JS code has the correct (camel) casing. [1]: import * as grpc from "@grpc/grpc-js";
import * as protoLoader from "@grpc/proto-loader"; |
|
What are talking about my phone
…On Thu, Jun 17, 2021, 3:01 AM k10-patil ***@***.***> wrote:
any updates on this?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<protocolbuffers/protobuf-javascript#17>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGWBKWOOJEUTRFUNNHRCMR3TTGMTTANCNFSM44Y7DD6Q>
.
|
TODO: 1. Figure out how to stop the generator from mangling the model property names into capital case (getCreatedat) See: https://github.com/protocolbuffers/protobuf/issues/8608 2. Figure out how to export the OpenAPI model classes and the gRPC model classes at the same time without name conflicts (they have the same names) 3. Implement streaming healthcheck endpiont with gRPC 4. Allow plugins to hook in their own gRPC service implementations. 5. Verify with test case that the secure credentials flavor also works. Fixes hyperledger-cacti#1189 Signed-off-by: Peter Somogyvari <[email protected]>
Primary change: -------------- The API server now contains a gRPC server in addition to what it had before (HTTP+SocketIO servers) so that through this it can provide the opportunity for plugins to expose their gRPC services via the Cactus API server. It is possible for plugins to serve their requests on multiple protocols at the same time which means that this is a big step towards our goal of being properly multi- protocol capable. Secondary change(s): ------------------- 1. The "allowJs" flag for the Typescript compiler is now specified as true for the cmd-api-server package which is necessary because without this the .js files generated by protoc do not get copied over from the ./src/main/typescript/generated/ folder to the ./dist/lib/.../generated folder with the rest of the build files. It is not ideal that we are generating JS code into the TS folder but it does come with .d.ts files and this is the "state of the art" at the moment becaues we can only do what the protocol buffer compiler will support and this is it. Later on we should improve on this situation once the tooling catches up and adds support to generate straight up TS code instead of JS+d.ts files so that we keep to our convention of having only TS code under ./src/main/typescript for obvious reasons. TODO: ---- 1. Figure out how to stop the generator from mangling the model property names into capital case (getCreatedat) See: https://github.com/protocolbuffers/protobuf/issues/8608 2. Figure out how to export the OpenAPI model classes and the gRPC model classes at the same time without name conflicts (they have the same names) 3. Implement streaming healthcheck endpiont with gRPC 4. Allow plugins to hook in their own gRPC service implementations. 5. Verify with test case that the secure credentials flavor also works. Fixes hyperledger-cacti#1189 Signed-off-by: Peter Somogyvari <[email protected]>
|
This is an absolute deal-breaker of using google-protobuf in javascript. |
|
I don’t think that google will change this behaviour anytime soon. also seen on #37 |
dibenede
added
bug
|
This is fixable and is inconsistent with other proto runtimes. However, it poses a compatibility problem. The issue is here: protobuf-javascript/generator/js_generator.cc Line 290 in a428c58 The immediate workaround is to use underscore_naming style rather than camelCase. The fix would be to flag gate the naming behavior. We'll need to consider which direction the flagging should operate. |
|
My suggestion: the default behavior should match the style guide (which calls for snake_case in field names, and CamelCase for the proto name), and have a flag to enable the extension (or extensions). If the flag's not set, this could emit a warning on seeing a CamelCase field name. P.S. I'm willing to take on this patch once we have agreement on how it should work. |
According to protobuf's guidelines: https://protobuf.dev/programming-guides/style/#message-field-names And because camelCase will be lost and become all lowercase in the generated TypeScript/JavaScript code: protocolbuffers/protobuf-javascript#17
According to protobuf's guidelines: https://protobuf.dev/programming-guides/style/#message-field-names And because camelCase will be lost and become all lowercase in the generated TypeScript/JavaScript code: protocolbuffers/protobuf-javascript#17
According to protobuf's guidelines: https://protobuf.dev/programming-guides/style/#message-field-names And because camelCase will be lost and become all lowercase in the generated TypeScript/JavaScript code: protocolbuffers/protobuf-javascript#17
syntax = "proto3";
message Test {
string some_field_with_camel_case = 1;
}https://protobuf.dev/programming-guides/style/#message-field-names |
What version of protobuf and what language are you using?
3.16.0 (Linux x86_64)
Javascript
Operation system
Ubuntu 18.04
What runtime / compiler are you using (e.g., python version or gcc version)
What did you do?
Create proto file (syntax 3)
run
Got
What did you expect to see
What did you see instead?
Camelcase is lost
The text was updated successfully, but these errors were encountered: