Third-party plugin docs should encourage more granular dependencies
- Dominant language
- Rust
- Stars
- 48.2k
- Forks
- 4.8k
- Avg merge
- 3d 16h
- Merged PRs (30d)
- 171
Description
## How can Bevy's documentation be improved?
The current third-party plugin guidelines suggest using `bevy` as the core dependency. This potentially introduces a heavy compile time bottleneck on the top level crate, which is exacerbated as there are some heavy dependencies in tree (i.e. `serde` and `wgpu`). This is likely to get progressively worse as the size and complexity of first party crates grows along with the ecosystem. Likewise, it also encourages plugin developers to target features on `bevy` instead of individual crates, leading to issues like #5753. To avoid this bottleneck, we should encourage plugin developers to directly depend on lower level `bevy_*` crates instead.
As @mockersf has noted [here](https://github.com/bevyengine/bevy/pull/6852#discussion_r1039063496), this does break potential discoverability via https://lib.rs/crates/bevy/rev. This is, however, potentially mitigated by encouraging plugin developers to take `bevy` on as a dev-dependency instead, for ease of use when making examples and tests.
Contributor guide
Research direction
Start with the third-party plugin guidelines referenced in the issue and review how they currently recommend declaring the bevy dependency. Update the guidance to favor lower-level bevy_* crates while suggesting bevy as a dev-dependency for examples and tests, then verify that the documented recommendation addresses compile-time costs and feature targeting.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100