#[non_exhaustive]pub struct Options {
pub buffa: CodeGenConfig,
pub gate_client_feature: bool,
}Expand description
Options for ConnectRPC code generation.
These control both the underlying buffa message generation and the ConnectRPC service binding generation.
Construct via Options::default() then set fields on buffa directly
(the struct is #[non_exhaustive], so struct-update syntax is
unavailable from outside this crate).
Fields (Non-exhaustive)§
This struct is marked as non-exhaustive
Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.buffa: CodeGenConfigThe underlying buffa-codegen configuration. Set any
CodeGenConfig field directly here; connectrpc passes it through
verbatim except for CodeGenConfig::generate_views, which is
forced to true (service stubs require view types).
Options::default() starts from buffa’s defaults but enables
generate_json (the Connect protocol’s JSON codec needs it; buffa’s
own default is false).
buffa.extern_paths is used by generate_services to bake
absolute paths into service stubs (set a (".", "crate::proto")
catch-all so every type resolves); it is ignored by
generate_files (the unified super::-relative path).
Every extern_path target must be buffa-generated code from
buffa ≥ 0.7.0 with views enabled (and, if the crate feature-gates
its generated impls, with that feature turned on): the service
stubs rely on the buffa::HasMessageView impls and FooOwnedView
wrappers emitted alongside each message, the same way they rely on
the JSON/Serialize impls. buffa-types 0.7+ satisfies this for
the well-known types. A crate generated without them fails to
compile against the stubs (missing HasMessageView impl).
gate_client_feature: boolWhen true, prefix every emitted FooClient<T> struct and its
impl block with #[cfg(feature = "client")]. Opt in when
the consuming crate wants to give server-only deployments a way
to drop the client transport stack from their dependency graph.