Use codegen from standard library crate

[oktal]

Hello, first of, thanks for this wonderful crate !

I have a very specific use-case that bon does not cover yet that I'd really love to have.
I have my own code-generation code, say from protobuf to Rust (I'm not using prost).

I generate Rust types for given messages defined in my .proto, eg:

message Stage {
  enum StageType {
    POWER = 0;
    FLOW = 1;
    PRESSURE = 2;
  }

  string name = 1;
  string key = 2;
  optional int32 temperature_delta = 3;
  StageType stage_type = 4;
}

will yield the following types:

pub enum StageType {
    Power = 0,
    Flow = 1,
    Pressure = 2,
}

pub struct StageDetached {
    pub name: ::std::string::String,
    pub key: ::std::string::String,
    pub temperature_delta: ::std::option::Option<i32>,
    pub stage_type: StageType,
}

Now, I want to generate a builder through bon for my StageDetached generated type.
I could simply derive bon' Builder for my StageDetached type like so:

#[derive(bon::Builder)]
pub struct StageDetached {
   // ... omitted
}

But that now means that users of my crate need to depend on bon, which I'd like to avoid.
Instead, I'd like to directly call bon codegen to generate the builders and include the result of bon codegen
to my already generated code.

However, I can not do that as bon does not publicly expose codegen through a regular crate (I don't think Rust will expose a proc-macro as regular rust functions ?).

I was able to create a new bon-gen library crate, move all the code generation from bon proc-macro to bon-gen and then directly depend on bon-gen to generate the code and include the result in my own generated code. It almost works, except that I still need to depend on bon to get private:: symbols that the generated code requires.

Before going any further, I'd like to know if this is change you were willing to accept and if so, maybe guide me in the right direction as I'd be willing to submit a PR for this.

A note for the community from the maintainers

Please vote on this issue by adding a 👍 reaction to help the maintainers with prioritizing it. You may add a comment describing your real use case related to this issue for us to better understand the problem domain.

[Veetaha]

Hi! This use case should be covered by #[builder(crate = rexport::path::of::bon)]. This parameter works exactly like it works in serde (see serde(crate = ...) here).

So when you generate code you should just generate it like this:

#[derive(my_crate::reexport::path::bon::Builder)]
#[builder(crate  = my_crate::reexport::path::bon)]
pub struct StageDetached { /**/ }

Unfortunately, this feature isn't released yet, but it's already in master. I'm currently preparing a 3.0 release of bon (the progress of that is tracked in #156). What's left is just writing the documentation for all the new features, including the #[builder(crate)] attribute, for which the docs aren't ready yet.

However, maybe you could add a dependency on the git master branch in the mean time? There shouldn't be any breaking changes in master (although it doesn't really matter because cargo will pin the specific commit in your Cargo.lock anyway). The implementations are done, and only docs are pending. The release should be some time this week.

bon = { git = "https://github.com/elastio/bon", branch = "master" }

The changelog for 3.0 is here, although it's not complete yet, but most importantly there probably aren't breaking changes noticeable by 99% of use cases.

[oktal]

Thanks, that's exactly what I was after 😍 ! I'm closing the issue for now