Stephen Haberman

Wow, how many fields do you have in you messages? I suppose we could detect "this message has more than `N` fields" and then output an explicit type annotation for...

@jacobfederer we just added an option to disable the `Exact` type, see #454; can you try enabling that option and see if that fixes it for you? If it does,...

Ah sure, that code is right around here: https://github.com/stephenh/ts-proto/blob/main/src/main.ts#L731 If you'd like to submit a PR to fix it, to use/check `isOptionalProperty` in `types.ts` (probably/1st guess), that'd be great. Thanks!

In the proto3, fields that are not included must always be handled, essentially as optional: https://developers.google.com/protocol-buffers/docs/proto3#default And so the ts-proto way of handling "the field wasn't in the encoded message"...

@ludusrusso well, it might be more than a few places, but I'd start around here, where we decide "should this field be optional": https://github.com/stephenh/ts-proto/blob/main/src/main.ts#L525 And then here is where we...

@peve yes, that looks like a bug, or more accurately a not-yet-supported combination of features/flags. :-) I believe the contributors (and/or me) who've worked on streaming haven't needed browser support...

Ah yeah, good question... Technically the readme mentions three reasons (typo prevention, more consistent API for readers, and ensuring proper message initialization), and you're right ts-proto `Exact` tries to/should prevent...

@oyvindwe yeah, agreed; fwiw I think ts-proto is due to have a major / 2.0 version release that upgrades some of the defaults / renames of the flags / etc....

@boukeversteegh wdyt re ^? Does it pique your interest? :-D

@elderapo unfortunately the PR is pretty out of date, and had several unanswered questions from the original review, plus an ask for a test, so as-is, chances of being merged...