-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support the jstype
field option
#556
Comments
Is there any consideration going into a global setting that would only change the generated types and not require changes to the schema? My backend team will probably not sign off on this request... |
Definitely considered. You'll be able to set the option for every relevant field - without changing proto files - with managed mode. Will most likely need just two lines in your buf.gen.yaml: managed:
enabled: true
override:
+ - field_option: jstype
+ value: JS_STRING I think this should be reasonable? |
This looks nice, but I'm also curious why there wouldn't be something in the override to denote the field type we're overriding. Without the implementation context, it would appear that every field would be changed to a string, not just managed:
enabled: true
override:
+ - field_type: int64
+ - field_option: jstype
+ value: JS_STRING |
Or another option (just brainstorming here) would be changing |
We're working with the field option defined in descriptor.proto here. I agree that it's not the best name, but it is unlikely that we can rename the option. |
I didn't realize this was a core protobuf definition, but it explains why the linked PR is for buf and not protobuf-es. We were really surprised to see it there originally. Glad there's a path forward! |
@tannerlinsley, @derekperkins, this feature has just been released in v1.4.0. The managed mode feature from bufbuild/buf#2311 is not available yet, but the option can of course be manually specified on fields. |
In protobuf, fields with a 64-bit integral type can be annotated with the
jstype
field option:The reason this option exists is that the JavaScript Number primitive cannot safely represent the full range of 64-bit integers. The option predates BigInt, but since BigInt has drawbacks for some users, we can honor this option to represent 64-bit integers with String.
The buf CLI will support setting this field in managed mode (see this related PR).
The text was updated successfully, but these errors were encountered: