support build options for filed type

[BeatsKitano]

This is a wonderful plugin! thank you for open source.
I have a little issue.this is my proto file hello.proto:

syntax = "proto3";

message Reply {
	string id = 1;  
}

this lib generate filed id type to string | undefined, but field id is define.
If id is optional, i think string | undefined is ok, now id is default required, the generate field type should be string, not string | undefined

version: latest

[ericwenn]

@BeatsKitano This is intentional, as the default value fields (for example 0 on an int) may be omitted from the json serialization of protobuf message.

See https://developers.google.com/protocol-buffers/docs/proto3#json

[shuqingzai]

If the required option is set, undefined should not be required, right? Now there will be undefined whether it is set or not

syntax = "proto3";

import "google/api/field_behavior.proto";

message Reply {
    string id = 1 [
        (google.api.field_behavior) = REQUIRED
    ];  
}

[ericwenn]

We've been discussing this internally, and landed on always setting type to T | undefined, as it will be consistent across proto versions and behavior.

For example REQUIRED might mean the value must be set on input, but does it require it to be set on output?

[shuqingzai]

1. Perhaps you're right. Described at https://google.aip.dev/203
2. It is again required when generating openapi documentation at protoc-gen-openapi
3. There is no field to indicate that the response is required, which makes it very difficult for front-end personnel

[ericwenn]

Regarding 3, there is a comment including the field behavior, for example:

// The resource name of the origin site of the shipment.
// Format: shippers/{shipper}/sites/{site}
//
// Behaviors: REQUIRED
originSite: string | undefined;

I'd be open to having build options for controlling this. Feel free to create a PR.

[seanlafferty-ibm]

A lot of AIP field behavior is dependent on which RPC is calling it. Most code generators (eg grpc_gateway openapi generator) do not handle this nuance well. Another case is the IDENTIFIER field_behavior https://google.aip.dev/203#identifier. It should be !undefined in a List/Get RPC response, but be omitted entirely from a Create RPC request.

I think protobuf is ultimately a leaky abstraction for these situations... evidenced by how many field mechanisms we have (optional, field_behavior, editions, etc).

That being said, this library is targeting typescript directly rather than an intermediary like openAPI, and typescript is quite expressive, so I think we could square this circle using typescript's utility types.

Ex:

export type CreateProjectRequest = {
  project: Omit<Project, "name">; // Since this is a Create() req, it's illegal to send an IDENTIFIER field, so omit it from the type
};

export type ListProjectsResponse = {
  projects: Project & {name: string}[]; // Since this is a List() resp, IDENTIFIER fields must be present, so make them non-null
  nextPageToken: string | undefined;
};

export type Project = {
  // Behaviors: IDENTIFIER
  name: string | undefined;
};