Summary
connectrpc-build's Config surfaces several buffa codegen options as first-class convenience setters (generate_json, strict_utf8_mapping, emit_register_fn, file_per_package), plus a wholesale buffa_config(CodeGenConfig) escape hatch. But it does not surface buffa's options for gating the generated message-type impls behind crate features:
gate_impls_on_crate_features
gate_reflect_on_crate_feature
feature_gate_names (the FeatureGateNames struct, with the customizable json / reflect / etc. names)
So an integrator who wants their generated message types' serde (json) impls gated behind a custom-named feature has to call buffa_config(...) and build a whole CodeGenConfig by hand. Because buffa_config replaces the config wholesale, it does not compose with the other convenience setters — you lose generate_json, strict_utf8_mapping, etc. unless you re-set them on the CodeGenConfig yourself.
Proposal
Add convenience passthrough setters on connectrpc-build::Config that forward to the underlying buffa CodeGenConfig, e.g.:
gate_impls_on_crate_features(bool)
gate_reflect_on_crate_feature(bool)
- a setter (or builder) for the feature-gate names (
json, reflect, ...)
so message-type feature gating can be configured alongside the existing convenience setters, without dropping to the wholesale buffa_config escape hatch.
Why
This is the integration point for buffa's customizable-feature-name support: the json gate that integrators may want to customize lives on the message types, which buffa generates and connectrpc-build drives. The capability already exists (via buffa_config); this issue is about first-class ergonomics and discoverability, and consistency with the other buffa options connectrpc-build already re-exports.
Notes / priority
Low priority and additive. A separate issue covers making connectrpc-codegen's own client feature gate name configurable; this one is specifically about the connectrpc-build → buffa passthrough for message-type gating.
Summary
connectrpc-build'sConfigsurfaces several buffa codegen options as first-class convenience setters (generate_json,strict_utf8_mapping,emit_register_fn,file_per_package), plus a wholesalebuffa_config(CodeGenConfig)escape hatch. But it does not surface buffa's options for gating the generated message-type impls behind crate features:gate_impls_on_crate_featuresgate_reflect_on_crate_featurefeature_gate_names(theFeatureGateNamesstruct, with the customizablejson/reflect/ etc. names)So an integrator who wants their generated message types' serde (
json) impls gated behind a custom-named feature has to callbuffa_config(...)and build a wholeCodeGenConfigby hand. Becausebuffa_configreplaces the config wholesale, it does not compose with the other convenience setters — you losegenerate_json,strict_utf8_mapping, etc. unless you re-set them on theCodeGenConfigyourself.Proposal
Add convenience passthrough setters on
connectrpc-build::Configthat forward to the underlying buffaCodeGenConfig, e.g.:gate_impls_on_crate_features(bool)gate_reflect_on_crate_feature(bool)json,reflect, ...)so message-type feature gating can be configured alongside the existing convenience setters, without dropping to the wholesale
buffa_configescape hatch.Why
This is the integration point for buffa's customizable-feature-name support: the
jsongate that integrators may want to customize lives on the message types, which buffa generates andconnectrpc-builddrives. The capability already exists (viabuffa_config); this issue is about first-class ergonomics and discoverability, and consistency with the other buffa optionsconnectrpc-buildalready re-exports.Notes / priority
Low priority and additive. A separate issue covers making
connectrpc-codegen's ownclientfeature gate name configurable; this one is specifically about theconnectrpc-build→ buffa passthrough for message-type gating.