Hide some re-exports by default.

[mintlu8]

Objective

Re-exports of accesskit, tracing, tracing_subscribers and hashbrown are very annoying when using auto-complete.

Solution

• Applied #[doc(hidden)] to re-exports of accesskit, tracing, and hashbrown, that causes issues when using editors.

• Removed tracing_subscribers re-export.

• Added feature unhide_reexports to un-hide them.

Testing

Tested with with VSCode.

Migration Guide

• bevy_log::tracing_subscribers has been removed.
• bevy_utils::hashbrown, bevy_utils::tracing and bevy_a11y::accesskit are no longer a part of bevy's public API and are no longer guaranteed to be exported in future versions.

[alice-i-cecile]

Why do this rather than just removing the re-exports?

[mintlu8]

Why do this rather than just removing the re-exports?

Maximum backwards compatibility 😄, I'm fine with cutting them.

[alice-i-cecile]

I'd prefer to cut them: I haven't seen anyone clamoring for these, unlike those from glam.

[mintlu8]

I'd prefer to cut them: I haven't seen anyone clamoring for these, unlike those from glam.

None of them are "cuttable" due to them all being used by various macros. I removed the feature and used #[doc(hidden)] directly.

[github-actions]

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

Could you add some context on what users should update when this change get released in a new version of Bevy?
It will be used to help writing the migration guide for the version. Putting it after a ## Migration Guide will help it get automatically picked up by our tooling.

[alice-i-cecile]

Hmm, I like this better than the status quo.

Can't we just use absolute imports in the macros instead?

[mintlu8]

Hmm, I like this better than the status quo.

Can't we just use absolute imports in the macros instead?

Removed tracing_subscribers. The other three are good for project organization imo.

• hashbrown is exported because bevy_util::HashMap is a typedef with a pre-set hasher, while Reflect is implemented on a generic hasher.
• accesskit is currently not on the latest version, keeping it in bevy_a11y keeps things consistent.
• tracing is used by crates lower on the dependency chain than bevy_log like bevy_ecs.
  Replacing it with absolute import is an option though.

[mockersf]

I would prefer to keep the re-export, otherwise people using Bevy API need to keep the dependencies at the same version as Bevy or risk incompatibilities

[alice-i-cecile]

Alright, I can get behind that. So keep the re-exports, but hide them so they don't junk up the auto-complete.

[mockersf]

I don't know for others, but I use the re-exports of tracing and tracing-subscriber and usually relies on auto-complete to get them right, so I would prefer them to not be hidden

[mintlu8]

I don't know for others, but I use the re-exports of tracing and tracing-subscriber and usually relies on auto-complete to get them right, so I would prefer them to not be hidden

Let me counter this a little bit. tracing is very stable, tracing-subscriber is somewhat stable so I don't expect version mismatch to be a huge problem, without bevy exporting them it takes one import per project to get them working, vs Handle being autocompleted to tracing-subscriber::..::Handle which takes a lot of time.

hashbrown is probably not pulled in by the user, since it's in bevy_utils.

The only contentious crate is accesskit. I think maybe add a feature flag like accesskit just to publicly re-export it?

[alice-i-cecile]

accesskit's naming is really prone to clashing with existing functionality in Bevy's apps. IMO a feature flag is less discoverable / typical than the standard "just pull your own dependency" pattern, and cargo-deny is solid at catching duplicate versions in tree. And it's not really any more convenient either.

[mockersf]

could we re-export the few items most often used instead of a blanket re-export of the whole crates?

[mintlu8]

could we re-export the few items most often used instead of a blanket re-export of the whole crates?

What would be the common used items?

I can only think of span! and Span from tracing, which are currently not in bevy_log.

Not sure what you would want from tracing_subscriber as a user since bevy takes care of logging pretty well. It's hard to get anything out of it if you don't have the whole crate.

No idea about accesskit.