Feature request: InternalBinaryWrite configurable to force writing non optional fields

[ivalduan]

Looking at the spec of proto3 the behavior of not writing fields when the value is equivalent to the default is expected

Also note that if a scalar message field is set to its default, the value will not be serialized on the wire.

In order to be compatible with proto2 serialization it would be great to have an option that allows the override of this behavior and serializes always non-optional fields, the changes required seem to be fairly small. It could be even automatic detecting the syntax statement when reading proto.

Let me know if a PR related with this would be of interest.

[timostamm]

Full proto2 support requires quite a few changes, see https://github.com/timostamm/protobuf-ts/blob/master/MANUAL.md#proto2-support

I think it would translate into new code paths for the plugin, the runtime, and in the generated code as well. This will increase complexity quite a bit, and might also impact performance for the reflection based operations.

Maybe there is a way to selectively only special case proto2 required fields, but I'm not sure what exactly this would entail, and I'm wondering how far it would get us towards full proto2 compatibility. The conformance tests unfortunately only cover proto3.

Do you have a use case for serializing proto2 messages?

[ivalduan]

In this case I need to be compatible with some proto2 schemas between different programming languages. The only incompatibility encountered using this framework was some required fields not being written on serialization when their value is the default, but reading the provided link I see it being a bit more involved. I think this point 4 sentence is not accurate, the framework infers and generates correctly all interface types.

4. required label is not supported: If a field has the required label, the type will be myField: bool with the default value false.

I was able to move forward by adding some quick and dirty code to InternalBinaryWrite.scalar. If protobuf-ts prefers to stay on proto3 only support what framework would you recommend for proto2 typescript code generations?

[timostamm]

It looks like the official implementation and protobuf.js both support proto2. I recommend going with one of them. However, if you have a migration to proto3 on your roadmap somewhere, I would personally use protobuf-ts with a patch.