Struct Config 

pub struct Config { /* private fields */ }

Provides configuration options for the generated code.

Acquire an instance with the new function, then add any attributes as needed before passing to generate_protos.

Each attribute function consumes the current instance of Config and returns an updated one. Calls may be chained, like so:

let config = Config::new()
    .type_attribute("some.package", "#[my_attr]")
    .message_attribute("some.package.MyMessage", "#[message_specific_attr]")
    .server_mod_attribute("other.package", "#[server_module_attr]");

Alternatively, declare your config variable as mutable and replace it with each call:

let mut config = Config::new();
config = config.type_attribute("some.package", "#[my_attr]");
config = config.message_attribute("some.package.MyMessage", "#[message_specific_attr]");
// ...

Implementations

impl Config

pub fn new() -> Self

Create a default Config.

Applies the following baseline settings to the underlying tonic_prost_build::Builder:

• emit_rerun_if_changed(true) — Cargo will re-run build.rs when any .proto file changes.
• compile_well_known_types(true) — generates google.protobuf.* types alongside the service types.
• #[derive(::rust_grpc_lib::GrpcClient)] on every client struct — when the auth feature is enabled (the default).
• #[derive(::rust_grpc_lib::GrpcNoAuthClient)] on every client struct — when the unauthenticated feature is enabled.

pub fn client_attribute(self, path: &str, attribute: &str) -> Self

Add an additional attribute to generated gRPC client service structs.

Differentiation from other attribute functions

• Scope: gRPC-specific tooling. This targets the generated implementation client (e.g., pub struct MyServiceClient<T>).
• Vs server_attribute: Modifies the outgoing client consumer types, leaving the server handler traits untouched.
• Vs type_attribute / message_attribute: Data-layer configurations (type_attribute) target the underlying data shapes. Service-layer configurations (client_attribute) target the communication infrastructure generated by tonic.
• Vs client_mod_attribute: Attaches to the actual client code items, whereas client_mod_attribute wraps the module container boundary.

Examples

use rust_grpc_lib::build_support::Config;

let mut config = Config::new();
// Attaches a mock trait derive directly onto the generated gRPC client struct
config = config.client_attribute("my_package.MyService", "#[derive(mockall::automock)]");

pub fn client_mod_attribute(self, path: &str, attribute: &str) -> Self

Add an additional attribute to the module namespace block containing the client stubs.

Differentiation from other attribute functions

• Scope: Architectural boundary/Module encapsulation. Targets the generated pub mod my_service_client statement.
• Vs client_attribute: client_attribute edits things inside the module (like the client struct itself). client_mod_attribute gates or tags the entire parent module.
• Vs server_mod_attribute: Isolates compilation properties strictly for your client implementations, ignoring server scopes. This is commonly used for conditional compilation (e.g., #[cfg(feature = "client")]) so client modules don’t compile when the feature flag is missing.

Examples

use rust_grpc_lib::build_support::Config;

let mut config = Config::new();
// Conditionally compiles the entire client module structure using cargo feature gates
config = config.client_mod_attribute("my_package.MyService", "#[cfg(feature = \"client\")]");

pub fn enum_attribute(self, path: &str, attribute: &str) -> Self

Add an additional attribute to matched standalone enum definitions.

Differentiation from other attribute functions

• Scope: Enums exclusively. It targets only Rust enum structures generated from formal, standalone Protobuf enum blocks.
• Vs type_attribute: type_attribute applies macros globally to both structs and enums. enum_attribute filters out message structs, ensuring your macro only runs on actual enum choices.
• Vs message_attribute: Exact opposites. message_attribute exclusively targets struct types, while enum_attribute strictly targets enum types.
• The oneof Caveat: Inside a generated .rs file, a Protobuf oneof block is compiled as a Rust enum to wrap exclusive variant fields. However, enum_attribute does not catch these fields. To attach macros to a oneof enum structure, you must explicitly use type_attribute paired with the exact field path.

Examples

use rust_grpc_lib::build_support::Config;

let mut config = Config::new();
// Derives enum-specific utilities (like string mapping) only on standalone enums
config.enum_attribute("my_package.UserRole", "#[derive(strum::EnumString, strum::Display)]");

pub fn field_attribute(self, path: &str, attribute: &str) -> Self

Add an additional attribute to individual struct fields or enum variants.

Differentiation from other attribute functions

• Scope: Sub-item block placement. It injects code inside the generated data types, directly above individual struct fields or the variants inside a oneof enum block.
• Vs type_attribute / message_attribute: Those methods append attributes to the top level of the type declaration. field_attribute is used exclusively for property-level tuning, such as field skipping, renaming, default values, or target serialization hooks.

Examples

use rust_grpc_lib::build_support::Config;

let mut config = Config::new();
// Injects a serde rule directly above the `hashed_password` struct field
config = config.field_attribute("my_package.User.hashed_password", "#[serde(skip_serializing)]");

pub fn message_attribute(self, path: &str, attribute: &str) -> Self

Add an additional attribute to matched messages specifically.

Differentiation from other attribute functions

• Scope: Strict struct-only type-level macro. It targets only Rust struct definitions generated from Protobuf messages.
• Vs type_attribute: It automatically ignores all enum items and oneof enums. This is useful if you use a derive macro that works safely on structs but panics or fails when applied to enums.
• Vs field_attribute: Modifies the top-level message definition item, not individual fields within it.

Examples

use rust_grpc_lib::build_support::Config;

let mut config = Config::new();
// Applies a struct-specific macro only to the "User" message struct, ignoring enums
config = config.message_attribute("my_package.User", "#[derive(SomeStructOnlyMacro)]");

pub fn server_attribute(self, path: &str, attribute: &str) -> Self

Add an additional attribute to generated gRPC server trait implementations.

Differentiation from other attribute functions

• Scope: gRPC-specific tooling. Targets the generated trait defined for the server interface (e.g., pub trait MyService) and the generated service server dispatcher (pub struct MyServiceServer<T>).
• Vs client_attribute: Modifies only the server side of the contract, ignoring the client dispatcher code block.
• Vs server_mod_attribute: Attaches to specific inner server structs/traits, while server_mod_attribute applies attributes to the outer enclosing module scope.

Examples

use rust_grpc_lib::build_support::Config;

let mut config = Config::new();
// Forces a specific custom handling or restriction macro directly onto the server trait
config = config.server_attribute("my_package.MyService", "#[custom_server_gate]");

pub fn server_mod_attribute(self, path: &str, attribute: &str) -> Self

Add an additional attribute to the module namespace block containing the server stubs.

Differentiation from other attribute functions

• Scope: Architectural boundary/Module encapsulation. Targets the generated pub mod my_service_server statement.
• Vs server_attribute: Modifies the parent module containing the server structures instead of modifying the internal server trait elements.
• Vs client_mod_attribute: Isolates compilation traits specifically for the server environment. This is typically used to append module-wide documentation rules, clippy lint overrides, or conditional features (e.g., #[cfg(feature = "server")]) to avoid tracking server logic on clean client dependencies.

Examples

use rust_grpc_lib::build_support::Config;

let mut config = Config::new();
// Disables specific Clippy warnings across the entire generated server codebase module
config = config.server_mod_attribute("my_package.MyService", "#[allow(clippy::too_many_arguments)]");

pub fn type_attribute(self, path: &str, attribute: &str) -> Self

Add an additional attribute to matched messages, enums, and oneof types.

Differentiation from other attribute functions

• Scope: Broadest type-level macro. Applies to both struct definitions (generated from Protobuf messages) and enum definitions (generated from standalone enums or oneof groupings).
• Vs message_attribute: type_attribute modifies both structs and enums. Use message_attribute if you want to target structs exclusively.
• Vs field_attribute: Operates on the root container definition (struct MyMessage), whereas field_attribute operates on properties inside the container (pub my_field: String).

Examples

use rust_grpc_lib::build_support::Config;

let mut config = Config::new();
// Derives Serialize/Deserialize for EVERY message and enum under the package
config = config.type_attribute(".", "#[derive(serde::Serialize, serde::Deserialize)]");

Trait Implementations

impl Default for Config

fn default() -> Self

Returns the “default value” for a type.