Protobuf.js: --force-number does not work

[adarob]

When we generate output with --force-number we still are getting Longs when we decode a proto that is serialized with encode.

[Tarnadas]

I am also experiencing this issue, but it seems like the code generation is fine.
At runtime however I always get a Long even though I didn't even install the dependency!
After rimrafing node_modules/long I got a JS number as expected.
I think moving long from dependencies to optionalDependencies should solve the issue?

[glasser]

--force-number seems to only affect generated TypeScript types — it doesn't actually disable the search for long.js.

[kskalski]

I wasn't able to find an option, that would effectively disable use of Longs or bring consistent formatting for int64 fields (especially as keys of Map fields, for which the key is always converted to "hash" string with byte representation of int64).

However accidentally on a new project I found that not having Long properly linked and thus scrapped by bundler suddenly fixed all my previous problems and kept int64 consistently as number in both map keys and in fields.

Surely disabling Long is not an option for everyone (e.g. when actual values > 2^52 are needed) and shouldn't be done by default (at least until implementing support for BigInt), but there should exist such option. --force-number seems like a good candidate.

Anyway, for now I just added "rm -dfr node_modules/long" into my post "npm install" script and it works great. Maybe making it an optional dependency as @Tarnadas mentioned is a better way to do it.

[nihalgonsalves]

For now, instead of modifying the dependencies, you can also disable Long support explicitly along with using --force-number:

// @ts-expect-error Explicitly disable long.js support
protobufjs.util.Long = undefined;
protobufjs.configure();

This should ideally be automatically implied and handled by the flag (i.e. Long should not be used at all by the generated file).

Moving Long to optionalDependencies _may_ solve the issue, but without protobufjs explicitly handling it, the problem could come back when you add some other package that depends on Long.

[zim32]

protobufjs.util.Long = undefined;
protobufjs.configure();

Ok it helps, now I have number instead of Long, but... if i call JSON.stringify(message) I got string again.. My brain explodes.