[JS] toString on proto.google.protobuf.Int64Value doesn't return the correct value on large numbers

[neurojab]

Create a proto.google.protobuf.Int64Value with the value 9223372036854775807

Call toString on it. You'll get back 9223372036854776000

I'm sure it's converting it to a JS Number then converting it to a string, which is exactly what I don't want it to do.

I'm also interested in any workarounds.

[neurojab]

Tried using the js_type field option, but that doesn't work on wrapper types because that option is undefined on wrappers. ( It also doesn't work on unwrapped types due to a missing setProto3StringIntField function on Message. ) .

[cmoad]

js_type is definitely the right answer, which is why I opened protocolbuffers/protobuf#4025. I also submitted protocolbuffers/protobuf#4332 to address the missing function. Waiting on a response.

[TeBoring]

I am working on releasing setProto3StringIntField to opensource.
It seems to me the Int64Value need to have js_type = JS_STRING.

[cmoad]

Thanks for the update @TeBoring.

It seems to me the Int64Value need to have js_type = JS_STRING.

I wanted to confirm that this is my understanding as well and I use that field annotation throughout my protos.

[TeBoring]

Yes, if you want to avoid data loss you should use JS_STRING.

[amelhaoui]

Hi @TeBoring,

Please, is there any update on this?

I also get that TypeError: jspb.Message.setProto3StringIntField is not a function. Any alternatives? I'm trying to get rid of our 64bit wrappers.

Thanks

[nickpresta]

@TeBoring it seems like a fix is to add [jstype = JS_STRING]; to the wrappers. Is this something that we're waiting on to land in the opensource version, or can I submit a patch?

[fgblomqvist]

Any update to this issue regarding the wrappers, sounds like @nickpresta's suggested solution is easy to implement?

[dibenede]

Duplicate of #67 , #21