feat: add generate options

[moecasts]

make generate configurable

// UseProtoNames controls the casing of generated field names.
// If set to true, fields will use proto names (typically snake_case).
// If omitted or set to false, fields will use JSON names (typically camelCase).
use_proto_names: bool

// UseEnumNumbers emits enum values as numbers.
use_enum_numbers: bool

// The method names of service methods naming case.
// Only work when `UseEnumNumbers=true`
// opt:
// camelcase: convert name to lower camel case like `camelCase`
// pascalcase: convert name to pascalcase like `PascalCase`
// default is pascalcase
enum_field_naming: string

// Generate comments as multiline comments.
// multiline comments: /** ... */
// single line comments: // ...
use_multi_line_comment: bool

// force add `undefined` to message field.
// default true
force_message_field_undefinable: bool

// If set to true, body will be JSON.stringify before send
// default true
use_body_stringify: bool

// The method names of service methods naming case.
// opt:
// camelcase: convert name to lower camel case like `camelCase`
// pascalcase: convert name to pascalcase like `PascalCase`
// default is pascalcase
service_method_naming: 'camelcase' | 'pascalcase'

// If set to true, field int64 and uint64 will convert to string
force_long_as_string: bool

Inspirit from:

• Add generate options #78
• https://github.com/stephenh/ts-proto#supported-options

[ericwenn]

Thanks for this PR!
Overall I'm positive to this change, but left some comments for improvments and questions.

[ericwenn]

Where does this come from?

[ericwenn]

Ah I see it now, see comment on the use_body_string option.

[ericwenn]

Why does the comment formatting need to be configurable?
I'd rather pick one of the formats (single/multi) and always use that, not configurable.

[moecasts]

because multiline comments is readable in ide tips dialog.

and make comment formatting be configurable is to aviod breaking change(Maybe it's just me worrying too much).

[ericwenn]

While I'm all for having this option, I understand it as you are also using that as a way to pass options to the request handler?

I would rather see a new argument to the request handler - something like handlerOptions: T - than spreading it into the request body.

[moecasts]

noop, at this monent, JSON.stringify is a mandatory behavior.

protoc-gen-typescript-http/internal/plugin/servicegen.go

Lines 167 to 170 in d11ee37

	f.P(t(3), "const body = JSON.stringify(request);")
	default:
	nullPath := nullPropagationPath(httprule.FieldPath{rule.Body}, input)
	f.P(t(3), "const body = JSON.stringify(request?.", nullPath, " ?? {});")

add this option is remove it, and the default value is true to avoid breaking change.

if someone like to use JSON.stringify, this option can be enabled, or archive it in requestHandler.

[ericwenn]

Should this just be called long_as_string instead? Not sure where the force comes from ;)

[moecasts]

This name is borrowed from: https://github.com/stephenh/ts-proto

I would like to borrow from the existing naming rather than define a new one.

Of course, if you really don't like it, I can change it.