Merge dependency features into root crate (hakari-style behavior)

[brndnmtthws]

A key feature of cargo-hakari is its ability to merge feature flags into the dependencies of the hack/root crate. This significantly reduces redundant recompilation in large workspaces.

In standard Cargo behavior, if two workspace crates (e.g. A and B) both depend on the same crate but enable different feature sets, Cargo will build that dependency multiple times. This also leads to frequent recompilation when switching targets.

A common workaround is to enable the full, merged feature set at the workspace root and declare the dependency there, then have inner crates depend on it via:

dep = { workspace = true }

This works well in practice for most cases and dramatically improves compile times. There are known edge cases (e.g. mutually exclusive features), so an escape hatch or override mechanism is still necessary, but the general approach is effective.

It would be valuable if cargo-rail supported a similar feature-merging mechanism, either automatically or via configuration, to consolidate dependency features at the root crate and avoid redundant builds.

The cargo-hakari documentation explains the motivation and behavior clearly:
https://docs.rs/cargo-hakari/latest/cargo_hakari/about/

As a workaround, I created my own python linter that can fix this, but cargo-rail is not really a replacement for hakari without this feature.

[loadingalias]

Hey @brndnmtthws!

Good news: this functionality already exists in cargo-rail, though with a deliberate design difference worth explaining.

Hakari uses 'union' - compile every feature anyone uses on every transitive dep. Benefit is zero rebuilds when switching between workspace subsets. Cost is a (significantly) fatter graph, compiling code paths some crates never touch, and potentially pulling in new transitive deps that weren't in your Cargo.lock. Not to mention, carrying the weight of the 'meta-crate' and added lockfile/CI steps.

cargo-rail uses intersection - compile only commonly-needed features. The graph stays minimal, Cargo.lock can't break, and you still eliminate fragmentation.

Hakari optimizes for one thing... zero rebuilds between workspace subsets. That's a narrow win that comes at the cost of graph bloat. cargo-rail optimizes for the minimal correct graph, which is what you actually ship and what CI actually builds. In practice, CI builds the whole workspace anyway (full unification), and incremental compilation handles the rare local re-add gracefully.

cargo-rail's multi-target resolution, version/dep unification, dead feature/dep pruning, and MSRV computation all work toward the same goal: the leanest possible graph. A "union everything" mode would undercut that design for zero added benefit from where I sit.

That said, I'm open. I've been running cargo-rail internally, privately, on a 60k-line systems codebase for nearly two years without hitting an edge case where I wanted union behavior. This is the codebase that's inspired cargo-rail.

If you're seeing something I'm not, talk it out with me. What's the scenario where intersection isn't enough? I'm genuinely grateful for your time, feedback, and opinions. What would you like to see and more importantly to me - why? What pain points are you experiencing when replacing hakari's union w/ cargo-rail's intersection?