I wrote this issue back in May, but seem to have forgotten to submit it?

Issue writeup below. I apologize if the details turn out to be somewhat out of date.

I'm sorry, none of the issue templates seemed to fit. "Feature Request" was the closest, but it didn't quite seem right.

Question

In README.md, you state that one of your design goals is to be modular; a user can choose to use only those features they need.
Yet the crate bevy_transform seems to bundle two unrelated concerns:

• The concept of a parent-child hierarchy of entities.
• The concept of a Transform, roughly a similarity transformation of Euclidean space.

Its description in Cargo.toml even admits this — "Provides hierarchy and transform functionality for Bevy Engine"! (Emphasis mine.)

Why aren't these two separate crates, with the latter depending on the former?

Reason

I discovered this issue while exploring the possibility of using Bevy to make games that take place in curved space.
The concept of a parent-child hierarchy is still completely applicable. But Transform, at least as currently implemented in Bevy, is not.

Details of Code Splitting

To ensure that this crate splitting would actually work, I tried it in a clone of the repository. Here are the results.

The crate bevy_transform was split into two: bevy_hierarchy and bevy_transform.

bevy_hierarchy contains these things:

• Everything in the modules components::{children, parent}.
• Everything in hierarchy and its submodules, except for the test in hierarchy::hierarchy_maintenance.

It has dependencies bevy_ecs, bevy_reflect, bevy_utils, and smallvec.
It does not need bevy_app or bevy_math.

bevy-transform contains everything else:

• Everything in the modules components::{transform, global_transform}.
• Everything in the module transform_propagate_system.
• Everything in the root module.
• The test from hierarchy::hierarchy_maintenance.

It depends on the new bevy-hierarchy, as well as bevy_app, bevy_ecs, bevy_math, and bevy_reflect.
It does not need bevy_utils or smallvec.

A few changes were necessary to get bevy_transform to compile again:

• Some imports needed to be fixed.
• In three instances, the code children.0.iter() started failing, because the field children.0 is private, and is now defined in a different crate. This was easily fixable; just do children.iter() (using the Deref impl) instead.

Finally, the dependent crates needed to be adjusted.

• bevy_scene depends on bevy_hierarchy, but not bevy_transform.
• bevy_gltf and bevy_ui depend on both bevy_hierarchy and bevy_transform.
• bevy_internal needed bevy_hierarchy added to its reexports and prelude.
• bevy_pbr, bevy_render, bevy_sprite, and bevy_text, despite depending on bevy_transform, seem to need no changes.

cargo --test passes. I have not done any performance testing.