Downstream code generators that emit per-proto content alongside buffa's output (service stubs, extra trait impls, etc.) currently have to tag their files as GeneratedFileKind::Owned so the per-package stitcher merges them into <stem>.rs. That works only because the stitcher matches by filename, and it's semantically misleading - the content isn't owned-message definitions.
connect-rust does this today (connectrpc-codegen/src/codegen.rs):
out.push(GeneratedFile {
name: format!("{}.rs", buffa_codegen::proto_path_to_stem(file_name)),
package: file.package.clone().unwrap_or_default(),
kind: GeneratedFileKind::Owned, // borrowed tag - not actually Owned content
content: service_code,
});
A dedicated variant (or an explicit "append to this file" hint) would let downstream generators participate without overloading Owned:
pub enum GeneratedFileKind {
Owned, View, Oneof, ViewOneof, Ext, PackageMod,
/// Extra per-proto content from a downstream generator. The stitcher
/// `include!`s it after the Owned file for the same stem.
Extension,
}
or alternatively a merge_into: Option<String> field on GeneratedFile so the caller names the target explicitly. Either is additive.
Downstream code generators that emit per-proto content alongside buffa's output (service stubs, extra trait impls, etc.) currently have to tag their files as
GeneratedFileKind::Ownedso the per-package stitcher merges them into<stem>.rs. That works only because the stitcher matches by filename, and it's semantically misleading - the content isn't owned-message definitions.connect-rust does this today (
connectrpc-codegen/src/codegen.rs):A dedicated variant (or an explicit "append to this file" hint) would let downstream generators participate without overloading
Owned:or alternatively a
merge_into: Option<String>field onGeneratedFileso the caller names the target explicitly. Either is additive.