Fix the issue with int64 value type in a map

[bobhfut]

As an employee from ByteDance, we have discovered a bug in our codebase. The issue occurs when a property in a protocol buffer (PB) structure is of type map<int32, int64>. When the value in the map is 0, the corresponding JavaScript value is represented as the number 0 instead of Long.ZERO.

We are working to fix this bug.

[dcodeIO]

Isn't the issue rather the value in, say, types.defaults["int64"]? Already does a lookup there, whereas the new isLongType seems redundant on this basis.

[bobhfut]

Isn't the issue rather the value in, say, types.defaults["int64"]? Already does a lookup there, whereas the new isLongType seems redundant on this basis.

The value stored in types.defaults["int64"] is the numerical value 0, but in reality we need to generate a string like "$util.Long ? $util.Long.fromValue(0) : 0" for all xx64 related types.

[bobhfut]

Isn't the issue rather the value in, say, types.defaults["int64"]? Already does a lookup there, whereas the new isLongType seems redundant on this basis.

maybe we just set types.defaults["xxx64"] to string "$util.Long ? $util.Long.fromValue(0) : 0" ?
The problem is that there are places where default values are being used to perform numeric comparisons.