#[non_exhaustive]pub struct Options {
pub buffa: CodeGenConfig,
pub gate_client_feature: bool,
pub client_feature_name: String,
pub encodable_impls: EncodableImpls,
}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.8.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.8+ 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 = "...")]. Opt in when
the consuming crate wants to give server-only deployments a way
to drop the client transport stack from their dependency graph.
client_feature_name: StringCargo feature name used when Options::gate_client_feature is
enabled (default: "client").
encodable_impls: EncodableImplsWhich messages get generated ::connectrpc::Encodable view impl
pairs (default: EncodableImpls::Outputs, plugin opt
encodable_impls=<all_messages|outputs>).
EncodableImpls::AllMessages emits the pair for every message
defined in each targeted proto and emits companion files even
for protos that declare no services. Use it in the generation run
of a crate that owns message types consumed by other crates’
services (a shared proto crate in a multi-crate split). Rust’s
orphan rules require the impl Encodable<M> for MView<'_> blocks
to live in the crate that defines the view type, so a downstream
service crate cannot emit them itself — its stubs skip foreign
(::-rooted extern_path) types and handlers fall back to owned
returns or PreEncoded::from_view. With the impls in the owning
crate, those handlers can return views of the shared types
directly (proto codec only — like every view body, they answer
JSON-codec requests with Unimplemented).
The emitting crate must depend on connectrpc, and the companion
files emitted for service-less packages must be mounted into the
module tree like any other plugin output — an unmounted companion
surfaces as a missing Encodable impl in the consuming crate.
Messages mapped away via
extern_paths are skipped, but
only ::-rooted targets are recognized as foreign — a
crate::-rooted re-export of another crate’s types would still
get (orphan) impls. Synthetic map-entry messages never get impls.
Enabling this in a service crate’s own run is harmless (impls dedup within one run), but do not enable it in two generation runs that feed one crate and cover the same protos — each run emits its own copy of the impls (E0119).