Function generate 

pub fn generate(request: &CodeGeneratorRequest) -> Result<CodeGeneratorResponse>

Generate a CodeGeneratorResponse from a protoc CodeGeneratorRequest.

This is the entry point for the protoc plugin (protoc-gen-connect-rust). It parses the comma-separated request.parameter into Options and delegates to generate_services — service stubs only. Callers must run protoc-gen-buffa (or equivalent) separately for message types.

Output

Per proto with at least one service: a <stem>.__connect.rs content file with the service stubs. Per package with at least one such proto: a <pkg>.mod.rs stitcher that include!s the content files. The stitcher filename intentionally matches protoc-gen-buffa’s, so run this plugin into a separate output directory and use protoc-gen-buffa-packaging to wire both trees, as shown in this repo’s buf.gen.yaml examples.

Under file_per_package the per-proto split is collapsed: one <dotted.pkg>.rs per package with all service stubs inlined, no per-proto content files, and no stitcher. Drop the protoc-gen-buffa-packaging invocations from your buf.gen.yaml under this layout — there are no per-file content files or stitchers for it to wire, and leaving it in produces dead mod.rs output without an error. Either let your downstream build tool synthesise the module tree from <dotted.package>.rs filenames (BSR cargo SDKs do this automatically) or hand-write the mod.rs. See generate_services.

A worked file_per_package buf.gen.yaml:

version: v2
plugins:
  - local: protoc-gen-buffa
    out: src/gen/buffa
    opt: [file_per_package]
  - local: protoc-gen-connect-rust
    out: src/gen/connect
    opt: [file_per_package, buffa_module=crate::gen::buffa]

You then mount each tree with a hand-written mod.rs (or let BSR’s cargo SDK pipeline do it):

pub mod buffa { /* one `pub mod <pkg> { include!("<pkg>.rs"); }` per package */ }
pub mod connect { /* same, pointing at src/gen/connect */ }

Recognized options

• buffa_module=<rust_path> — where you mounted the buffa-generated module tree (e.g. buffa_module=crate::proto). Shorthand for extern_path=.=<rust_path>. This is the option most local users want.
• extern_path=<proto>=<rust> — map a specific proto package prefix to a Rust module path. Repeatable; longest-prefix-match wins. extern_path=.=<path> is the catch-all (equivalent to buffa_module). At least one catch-all mapping is required so every type resolves.
• file_per_package — emit one <dotted.pkg>.rs per proto package instead of the per-proto split + stitcher. Set protoc-gen-buffa’s own file_per_package option to the same value — the BSR/tonic lib.rs synthesis assumes both plugins use the same filename convention; mismatched settings produce a valid but asymmetric layout you would have to wire by hand. Keep using a dedicated output directory (the documented split-path setup already does this) — the filename matches protoc-gen-buffa’s and would silently overwrite in a shared one. See CodeGenConfig::file_per_package for the strategy: directory constraint.
• strict_utf8_mapping — see CodeGenConfig::strict_utf8_mapping.
• no_json — disable serde derives on generated message types. Ignored in this plugin (no message types emitted); accepted for compatibility with the unified path.
• no_register_fn — suppress the per-file register_types(&mut TypeRegistry) aggregator. See CodeGenConfig::emit_register_fn. Ignored in this plugin (no message types emitted); accepted for compatibility with the unified path.