[Feature Request]: Derive entry per crate

[Arisa-Snowbell]

Feature Request

Derive entry per crate

Summary

Introduce separate derive macro entries grouped by their originating crate. Instead of combining all derives into a single attribute, derives would be organized into multiple #[derive(...)] blocks based on the crate they come from.

Motivation

Grouping derives by crate improves both readability and maintainability of the code. When derives from different ecosystems (e.g., serialization, archiving, standard traits) are separated, it becomes immediately clear which functionality is provided by which dependency.

This structure also makes it easier to:

1. Navigate and audit dependencies: Developers can quickly identify which crate is responsible for specific derives.
2. Modify or remove functionality: Adjusting or removing derives tied to a specific crate becomes straightforward without affecting unrelated ones.
3. Reduce cognitive load: Large, mixed derive lists can be difficult to scan; grouping them provides a more structured and predictable layout.
4. Improve consistency in larger codebases: Enforcing crate-based grouping encourages a standardized style across teams and projects.

Overall, this change promotes clearer intent, better organization, and easier long-term maintenance, especially in projects that rely on multiple derive-heavy libraries.

Related configuration options

merge_derives

Examples

#[derive(rkyv::Archive, rkyv::Serialize, rkyv::Deserialize)] // Rkyv derives
#[derive(serde::Serialize, serde::Deserialize)] // Serde derives
#[derive(Debug, Clone)] // Built-in derives
pub struct Donation {
    verification_token: Uuid,
    message_id: Uuid,
}

[ytmimi]

In order to support this feature request it might be a good idea to change merge_derives from a binary true or false option to an enum so users can specify how they want derives to be merged.

Because merge_derives is a stable formatting option we probably don't want to remove the ability to set it to true and false, but under the hood true and false could map to new enum variants for the option.

There current true and false behavior could be mapped to new variants like All and Off respectively, and I could see a nightly-only CommonPrefix variant getting added to support this feature request.

[Arisa-Snowbell]

I like that and sounds very reasonable