Skip to content

Conversation

@cart
Copy link
Member

@cart cart commented Oct 8, 2025

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:

default = ["2d", "3d", "ui"]

This enables developers to select only the features they need. For example, a UI-only app would look like this:

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.

@cart cart added this to the 0.18 milestone Oct 8, 2025
@cart cart added A-Build-System Related to build systems or continuous integration C-Usability A targeted quality-of-life change that makes Bevy easier to use A-App Bevy apps and plugins M-Release-Note Work that should be called out in the blog due to impact labels Oct 8, 2025
@github-actions
Copy link
Contributor

github-actions bot commented Oct 8, 2025

It looks like your PR has been selected for a highlight in the next release blog post, but you didn't provide a release note.

Please review the instructions for writing release notes, then expand or revise the content in the release notes directory to showcase your changes.

Copy link
Contributor

@atlv24 atlv24 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

@atlv24
Copy link
Contributor

atlv24 commented Oct 8, 2025

The feature generation tool will almost definitely not be able to cope with this, i noticed some weird edge cases a while back. Its going to need to be updated to display something meaningful for this

@github-actions
Copy link
Contributor

github-actions bot commented Oct 8, 2025

You added a new feature but didn't update the readme. Please run cargo run -p build-templated-pages -- update features to update it, and commit the file change.

Copy link
Contributor

@PROMETHIA-27 PROMETHIA-27 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could there be a headless configuration? Is that just default_app? My current usecase is a headless server.

@alice-i-cecile alice-i-cecile added X-Blessed Has a large architectural impact or tradeoffs, but the design has been endorsed by decision makers S-Needs-Review Needs reviewer attention (from anyone!) to move forward labels Oct 8, 2025
@alice-i-cecile alice-i-cecile added M-Migration-Guide A breaking change to Bevy's public API that needs to be noted in a migration guide S-Waiting-on-Author The author needs to make changes or address concerns before this can be merged and removed S-Needs-Review Needs reviewer attention (from anyone!) to move forward labels Oct 9, 2025
@github-actions
Copy link
Contributor

github-actions bot commented Oct 9, 2025

It looks like your PR is a breaking change, but you didn't provide a migration guide.

Please review the instructions for writing migration guides, then expand or revise the content in the migration guides directory to reflect your changes.

Copy link
Contributor

@atlv24 atlv24 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the toml docs heavily overuse "scare quotes" (try reading it without them, it flows better imo) but this is good to merge from a purely technical perspective

Cargo.toml Outdated
]

# Features used to build UI Bevy apps (this includes the bevy_render backend).
# Add this to your app if you would like the "default" Bevy UI experience.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
# Add this to your app if you would like the "default" Bevy UI experience.
# Add this to your app if you would like the default Bevy UI experience.

@cart
Copy link
Member Author

cart commented Oct 10, 2025

Ok this should be good to go. I've updated our cargo_features.md tooling to handle the concept of "feature profiles" and "feature collections" (take a look at the new generated cargo_features.md). Cargo features can opt-in to this designation with a COLLECTION: or PROFILE: prefix in their documentation.

This removes the "default" vs "non-default" feature presentation strategy. I consider that approach to be broken in its current form, as it doesn't accommodate the idea that features can contain other features (I believe that resulted in incorrect results before this PR). We can re-add that distinction if that is handled. But for now, I've switched to a sorted list of non-profile, non-collection cargo features.

audio = ["bevy_audio", "vorbis"]

# COLLECTION: Features used to compose Bevy scenes.
scene = ["bevy_scene"]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will this collection ever have any other entry? Why not just use bevy_scene?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, will bsn go here? bevy_bsn?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a high likelihood that the next generation scene system will be broken up into bevy_scene (everything but the bsn asset / macro) and bevy_bsn (bsn asset and macro).

Copy link
Contributor

@atlv24 atlv24 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@atlv24 atlv24 added S-Needs-Review Needs reviewer attention (from anyone!) to move forward and removed S-Waiting-on-Author The author needs to make changes or address concerns before this can be merged labels Oct 10, 2025
@alice-i-cecile alice-i-cecile added S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it and removed S-Needs-Review Needs reviewer attention (from anyone!) to move forward labels Oct 10, 2025
@alice-i-cecile alice-i-cecile added this pull request to the merge queue Oct 10, 2025
Merged via the queue into main with commit f3ec3c0 Oct 10, 2025
44 checks passed
mate-h pushed a commit to mate-h/bevy that referenced this pull request Oct 22, 2025
## 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: bevyengine#21369
Alternative to: bevyengine#20741 bevyengine#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 protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-App Bevy apps and plugins A-Build-System Related to build systems or continuous integration C-Usability A targeted quality-of-life change that makes Bevy easier to use M-Migration-Guide A breaking change to Bevy's public API that needs to be noted in a migration guide M-Release-Note Work that should be called out in the blog due to impact S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it X-Blessed Has a large architectural impact or tradeoffs, but the design has been endorsed by decision makers

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Shrink default feature set dramatically

6 participants