# Objective
Fix typos and other small issues in the documentation. I can drop the
changes to `bevy_reflect`'s and `bevy_anti_alias`'s crate descriptions
if it's a problem.
# Objective
- Bevy 0.17 does not have a feature named `2d`. It was introduced in
0.18.
- Feel free to change the PR title if it's ambiguous or close the PR if
I'm wrong.
## Solution
- Update to 0.18.
## Testing
- None
## Objective
Users of the `bevy` crate currently live one of two lifestyles:
1. Use all of Bevy's default features, potentially compiling many
features you don't need or don't want. If there is a feature you _cannot
have_ in your app, you must move on to option (2)
2. Disable Bevy's default features, and compose the complete list of
features yourself.
Living in the world of (2) is an exercise in frustration, as the list of
required features to accomplish a given task changes regularly across
releases as we add and change features. This is an _expert level_ task
that requires intimate knowledge of engine internals to get right. Even
I, Bevy's lead developer, would struggle here. To the point that I would
never voluntarily choose to disable Bevy's default features.
Most games/apps are 2D-only, 3D-only, or UI-only and don't require the
full set of features. We cannot currently in good conscience recommend
that those developers live in the "no default features" world. That is a
fast track to pain, suffering, and perhaps a quick exit from the Bevy
ecosystem.
The same problem exists for developers that want to build their own Bevy
renderer or replace Bevy UI with their own framework. Once again, we
_cannot_ recommend that those developers manage every Bevy feature
themselves.
Fixes: #21369
Alternative to: #20741#21236
## Solution
Define a "standalone" set of features that enable Bevy developers to
disable default features, then opt in to the funtionality they want. The
"default" `bevy` feature set is now just:
```toml
default = ["2d", "3d", "ui"]
```
This enables developers to select only the features they need. For
example, a UI-only app would look like this:
```toml
bevy = { version = "0.17", default-features = false, features = [ "ui" ] }
```
"2d", "3d", and "ui" each contain the "full" Bevy experience for that
domain. This also includes:
- `default_platform`: the default "platform support" features (see docs)
- `default_app`: the default "app framework" features (see docs)
For developers that do not want the default bevy render / platform / app
functionality, this breaks down further into:
- `common_api`: common / core backend-less user-facing Bevy render api
- `2d_api`: common / core backend-less user-facing Bevy 2d api
- `3d_api`: common / core backend-less user-facing Bevy 3d api
- `ui_api`: common / core backend-less user-facing Bevy ui api
(and many others)
I've also added the `dev` feature to this PR, which enables the
recommended "dev only" features like dynamic linking, asset watching /
hot reloading, and dev / debug tools. Including dynamic linking is a bit
controversial here given that it doesn't work everywhere. But I'd like
to aggressively push people into the dynamic linking workflow wherever
possible, as developing without it is signficantly worse. And removing a
single `dev` feature is a much simpler release workflow.
---------
Co-authored-by: atlv <email@atlasdostal.com>
# Objective
Bevy seems to want to standardize on "American English" spellings. Not
sure if this is laid out anywhere in writing, but see also #15947.
While perusing the docs for `typos`, I noticed that it has a `locale`
config option and tried it out.
## Solution
Switch to `en-us` locale in the `typos` config and run `typos -w`
## Migration Guide
The following methods or fields have been renamed from `*dependants*` to
`*dependents*`.
- `ProcessorAssetInfo::dependants`
- `ProcessorAssetInfos::add_dependant`
- `ProcessorAssetInfos::non_existent_dependants`
- `AssetInfo::dependants_waiting_on_load`
- `AssetInfo::dependants_waiting_on_recursive_dep_load`
- `AssetInfos::loader_dependants`
- `AssetInfos::remove_dependants_and_labels`
# Objective
- Fixes#1800, fixes#6984
- Alternative to #7196
- Ensure feature list is always up to date and that all are documented
- Help discovery of features
## Solution
- Use a template to update the cargo feature list
- Use the comment just above the feature declaration as the description
- Add the checks to CI
- Add the features to the base crate doc
DavidCrossman