Hello, I noticed that all my Cargo.toml files are filled with default-features = false, for almost every dependency I have. Is there a way to disable them for all dependencies of a crate/workspace?
jofas
April 16, 2025, 10:41am
2
No, default features need to be disabled on a per-dependency basis. There is an issue requesting this as a feature though:
opened 07:15AM - 28 Nov 24 UTC
C-feature-request
S-triage
### Problem
I see value in minimizing the dependency tree - only bring in what … I actually use.
The problem is that, between me using workspaces and features being additive, this creates *a lot* of noise in my manifest files, making them much harder to read.
As an example:
A small project I'm working on now, a set of three connected libraries in a workspace. There is a total of seven external non-dev dependencies, plus one or two intra-workspace ones. A total of around three thousand lines of Rust. `default-features = false` is found an astonishing *twenty six* times among the four manifest files.
I am most definitely not the only person doing this, as `cargo-deny` [has a ban for `default-features`](https://embarkstudios.github.io/cargo-deny/checks/bans/cfg.html#the-external-default-features-field-optional)
To show what it looks like:
```toml
[dependencies]
bytes = { workspace = true, default-features = false }
num_enum = { workspace = true, default-features = false }
thiserror = { workspace = true, default-features = false }
futures = { workspace = true, default-features = false, optional = true }
tokio = { workspace = true, default-features = false, features = ["macros"], optional = true }
tokio-util = { workspace = true, default-features = false, optional = true }
valuable = { workspace = true, default-features = false, optional = true }
```
### Proposed Solution
I would like an option that would allow me to, in one place, set `default-feature = false` for every dependency in the file manifest. Ideally, this would be three switches: separately for regular, dev and build dependencies.
The big issue I see with such an addition is that it does not fit within the existing structure of the manifest file - the obvious place to put it would be under `dependencies`, but that would create a precedent of Cargo itself reserving crate names, which I do not think is a good idea.
Other top level keys have their own roles, and adding this feature to them would not be suitable.
Just about the only option I see is adding a new top-level key to the manifest, perhaps one generally involved with governing default features. This option would be added under it.
### Notes
#3126 may be relevant to this discussion.