--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<int64, T> 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.

[kmsomebody]

Any updates on this?
Manually setting Long to undefined works, but this has to be done every time after pbjs/pbts is called.

The problem with Long is that toObject does not actually create a plain object, but an object with Long inside. This means in Next.js I can't pass the object from a server component to a client component, because the serialization does not work.

Of course it's possible to manually serialize/deserialize the object before/after passing it, but this is a major inconvenience that shouldn't be there, provided that the options that should make this possible are there but just not working properly.

[Tofandel]

This is what I'm running to really optimise the code by removing the branches that pbjs -t static-module -w wrapper.js --force-number --dependency protobufjs/minimal.js --es6 -o ./protos.js ../../../protos/* && sed -i s/\$util.Long/false/ protos.js && terser --compress -o protos.js -- protos.js

It still doesn't remove the long dependency so this will still be loaded, it should really be moved to an optional dependency

You can also use

MyProto.toObject(myProto, {
            arrays: true,
            objects: true,
            defaults: true,
            longs: Number, // This
});

To force it to be a number when serializing to an object