stephenh
Address optional fields issue with Exact
The README says that the default is not to use optional fields, and the main reason is to avoid accidentally setting the wrong field name, because we don't have Exact<T> to control ensuring that unknown fields don't exist.
However, it seems that these days Exact is defined by ts-proto, so, could it be used to ensure that the objects passed to encode() don't have any unknown fields?
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 the first one, but there are still the other two rationales.
Dunno, I don't feel as strongly about this optional/required issue as I did when first writing ts-proto, but I'm tempted to leave things as-is.
We could flip the default I guess, to useOptionals=all, but I don't have any analytics/data points on how many ts-protos users are using/overriding the default.
FWIW, in my opinion changing default behaviour is a breaking change (for build pipeles), and warrants a major release, so I would advocate against it. We are explicitly setting useOptionals=all, so it wouldn't affect us though.
In any case it sounds like the documentation should probably be rephrased a bit?
@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. Maybe if protobuf.js every ships long-js 5.0.0 support (which is ESM). :-)
Also fwiw I'm unlikely personally to drive that next around of 2.0/etc. release/clean up, just b/c personally I'm at a company now that uses GraphQL, so I'm not hands-on-keyboard using protobuf anymore.
I'm still happy to steward ts-proto along, but also am really open to a core group of contributors self-organizing and pushing the project to its next stage, if that's something anyone is interested in.