rust-lombok-macros

Rust Lombok Macros

Treat lombok-macros as a procedural-macro dependency and API generator, not as a complete Rust equivalent of Java Lombok. Confirm every generated method's signature, visibility, failure behavior, and compatibility boundary before removing boilerplate.

Scope

Use this skill for:

• DTOs, configuration snapshots, internal messages, test fixtures, and other data carriers where every field combination is valid;
• reducing mechanical methods with Getter, GetterMut, Setter, Data, or New;
• excluding explicitly identified sensitive fields with CustomDebug;
• reviewing existing attributes, upgrading the crate, or migrating handwritten methods.

Do not generate methods blindly for:

• domain entities, value objects, or security boundaries that require validation;
• methods with stable public contracts, custom errors, auditing, or side effects;
• Option or Result access paths that must preserve absence or error information;
• builders, default-value policies, serialization, comparisons, or hashing; version 2.0.32 does not provide these capabilities.

Route dependency versions, features, and supply-chain policy to rust-cargo-build; general procedural-macro implementation to rust-macros; API and security review to rust-code-review; and broader test design to rust-testing.

Workflow

1. Establish the exact baseline

Inspect the project instead of assuming a version:

rustc --version --verbose
cargo metadata --format-version 1
cargo tree -i lombok-macros -e features

Check Cargo.toml, Cargo.lock, the edition, rust-version, and supported targets. Version 2.0.32 uses Edition 2024 and does not declare a Rust version, so compile it on the project's actual MSRV. Do not infer the selected version only from the current crates.io page or a GitHub release badge.

When adding the dependency, use cargo add lombok-macros or an explicit reviewed version such as cargo add lombok-macros@2.0.32. Never copy lombok-macros = "latest" into Cargo.toml; Cargo dependencies use semantic version requirements, not a latest keyword.

2. Triage examples by crate version

Do not assume that a blog post, generated answer, or older snippet matches the locked crate. In particular, 2.0.32 does not export a Lombok derive. Rewrite examples such as #[derive(Lombok, Debug, Clone)] with the smallest current derives, for example #[derive(Getter, Setter, Debug, Clone)], or use Data only when mutable getters are also intended.

Keep capability ownership explicit:

• Debug and Clone are standard-library derives, not features generated by lombok-macros.
• CustomDebug is the crate-provided alternative when selected fields must be skipped.
• DisplayDebug and DisplayDebugFormat implement Display from an existing Debug representation; they do not make Debug output a stable presentation format.
• A procedural macro removes handwritten source but still adds compile-time work and generated behavior. Do not describe it as cost-free without qualification.

3. Inventory the pre-generation API

Record each field's existing method signature, visibility, ownership behavior, validation, side effects, errors, and callers. Replace a method only when the generated interface is equivalent or the contract change has been accepted.

Select the smallest derive:

Requirement	Derive	Default risk
Read-only access	Getter	Default Option and Result getters unwrap and return the inner value
Mutable borrowing	GetterMut	Callers can bypass field invariants
Direct replacement	Setter	Setters do not validate and add write access
All three accessor types	Data	The API surface is often wider than necessary
All-field construction	New	The constructor is public by default; skipped fields use Default
Redacted debug output	CustomDebug	New sensitive fields still require explicit review
Debug reused as Display	DisplayDebug*	Structural output leaks easily and is not a stable user contract

4. Make generated semantics explicit

Write attributes against the locked version's source and documentation. For 2.0.32:

use lombok_macros::{CustomDebug, Getter, New, Setter};

#[derive(Getter, Setter, New, CustomDebug)]
#[new(pub(crate))]
struct WorkerConfig {
    #[get(pub)]
    #[set(pub, type(Into<String>))]
    name: String,

    #[get(pub, type(copy))]
    #[set(pub)]
    workers: usize,

    #[debug(skip)]
    #[new(skip)]
    token: String,
}

• Return &T for expensive values unless callers require ownership.
• Use type(clone) only when cloning is part of the API contract.
• Use type(copy) when value semantics are required for a Copy field.
• Do not use the #[get(pub, clone)] shorthand shown in part of the documentation; the 2.0.32 parser requires type(clone).
• Use type(Into<T>) or type(AsRef<T>) for setter conversion, then compile the exact target type.
• Keep visibility minimal. Generated public methods become part of a library's semver surface.

Read Macro Reference for the complete derive and attribute matrix.

5. Preserve Rust invariants

• Keep handwritten new or try_new functions when construction validates state.
• Keep named methods when mutation requires validation, auditing, or coordinated field updates; do not generate Setter or GetterMut for those fields.
• For Option and Result, write explicit as_ref, as_deref, or container-returning methods. Reject default getters and type(deref) when they introduce panic paths.
• Mark keys, tokens, passwords, and personal data with #[debug(skip)], then test formatted output. Review every new field later.
• Write Display manually for CLI, user-facing error, or protocol output. Restrict DisplayDebug to internal diagnostics.

Read Adoption and Review when replacing existing methods or reviewing a pull request.

6. Test the expanded contract through callers

Add tests that call generated methods instead of only checking that the derive compiles:

cargo fmt --all --check
cargo check --workspace --all-targets --all-features
cargo test --workspace --all-targets --all-features
cargo clippy --workspace --all-targets --all-features -- -D warnings

Cover method visibility, return types, setter chaining, constructor argument order, new(skip) defaults, Debug redaction, and the continued enforcement of handwritten invariants. Rerun these contract tests after dependency upgrades. Use cargo expand for manual inspection when useful, but do not make a nightly-only tool the sole quality gate.

Completion Criteria

• Confirm the dependency version, source, edition, and project MSRV with a real build.
• Use the smallest derive instead of defaulting to Data.
• Confirm every generated method's signature, visibility, ownership, and panic behavior.
• Keep validation, invariants, side effects, and error semantics in explicit Rust code.
• Prevent sensitive fields from reaching Debug or Display, and do not expose Debug as user output.
• Pass fmt, check, test, and Clippy with tests that call the generated API.

Resources

• Macro and Attribute Reference
• Adoption, Migration, and Review Checklist
• Execution Scenarios
• examples/golden-lombok/: a compilable contract example locked to 2.0.32.

Upstream Sources

• crates.io: confirm the published version, checksum, license, repository, features, and dependency metadata.
• docs.rs 2.0.32: inspect the public derive macros and version-specific rustdoc; avoid the moving latest URL during implementation.
• GitHub source: inspect implementation history, tags, issues, and unreleased changes. Compare the matching release tag, not only the default branch.
• Rust Reference: procedural macros

If prose, rustdoc examples, and behavior disagree, treat the source included in the selected crates.io package as authoritative for generated code, reproduce the behavior in a minimal compile test, and document the discrepancy. Never silently substitute GitHub master behavior for the version in Cargo.lock.

Data Privacy

This skill does not collect, store, or transmit user data. Dependency changes may access a registry. Confirm authorization before accessing a private registry, changing credentials, or publishing a crate.