Stephen Haberman

Hey @danwsong ah yeah; pedantically the protobuf docs you link to are for the default protobuf JS library, and not necessarily part of the protobuf spec itself. But yeah I...

@moles1 hey, sorry for the late follow up here, but I agree with both of your observations; if you could submit a PR that changes both, that'd be great! Thanks!

@boukeversteegh yeah, good point that, if `JsonOf` was a mapped type, it would need to have conditionals to recognize the various "this TS native type --> this one-off JSON type"......

Hey @johnnysinger ; unfortunately Protobuf does not have a way to treat message fields as required (maybe it did in proto2?, but not in grpc/proto3). What the Java-style protobuf output...

For now renaming this to "Add defaults for message fields", which is how the other / Java / "canonical"-style protobuf outputs handle this situation. It seems pretty doable for ts-proto...

@badeAdebayo I'm not personally planning on working on this soon; PR's would be great if you're interested!

My initial/short-term suggestion would be to try and make a `DeepReadOnly` that you could use in your return types against the existing ts-proto types: https://github.com/Microsoft/TypeScript/issues/13923 Just as a better stop-gap...

@jonaskello nope; would be great if you wanted to submit a PR, the code to change would be right here: https://github.com/stephenh/ts-proto/blob/main/src/main.ts#L672

@jonaskello ah sure... FWIW I'd probably just thrown in an `as any` like: ``` const message = createBaseSimpleMessage() as any; ``` If we're in "readonlyTypes" mode. And personally since we're...

Ah shoot, right, we forgot we'll have to make new instances of lists and maps... @Vilsol would you like to take a look at ^?