ts-proto: Repeated fields can be undefined

It appears that a repeated field like this one:

   repeated Document documents = 2;

Simply gives this as output:

   documents: Document[];

But, if you use the standard NodeJS protobufjs serialization without adding defaults: true a deserialized message won’t actually contain a documents field.

So it seems more appropriate to output:

   documents: Document[] | undefined;

Or even:

   documents?: Document[];

Of course, it’s always possible to add an option to turn this on or off using a setting similar to --ts_proto_opt=stringEnums=true (which BTW does nicely fit the the enums: String override on the protobufjs (de)serializer).

I could help on a PR for this, but first wanted to check what the preferred solution could be.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 19 (12 by maintainers)

Commits related to this issue

Most upvoted comments

Message received and understood, I’ll pick it up… 🙂

Hey @mharsat , thanks for the report! I was worried about this, per discussion above, i.e. you’re right, this is “not proto3” behavior.

I was hoping that existing users of useOptional would be fine with this, but I guess you’re right that useOptionals as it was before this PR was only a type-system change and not a decoding behavior change, which is what this PR turned it into…

I’ll revert and push out a new version.

I like your description of forceOptionalRepeated … I kinda wonder if something like dontApplyDefaults or even matchJsonOffTheWire would be more higher-level/use-case-driven names given that afaiu that is what @dot-i is looking to achieve.