The core functionality of this crate, synchronizing component and resource data with an editor, isn't actually specific to Amethyst. Most of the functionality is still useful to projects that use specs directly, with only SyncEditorBundle using an Amethyst-specific API in order to make setup more user-friendly. It would be possible to expose an core API that only relied on specs so that a broader portion of the community could take advantage of this functionality.
That said, there is Amethyst-specific functionality that we would like to add in the future (e.g. default registration of Amethyst components and resources, showing the state machine stack, showing state event history, etc.). As such, it would likely make sense to split this project into two crates: One that provides specs-compatible functionality, and then continue to build the amethyst-editor-sync crate on top of the specs-only crate.
The core functionality of this crate, synchronizing component and resource data with an editor, isn't actually specific to Amethyst. Most of the functionality is still useful to projects that use specs directly, with only
SyncEditorBundleusing an Amethyst-specific API in order to make setup more user-friendly. It would be possible to expose an core API that only relied on specs so that a broader portion of the community could take advantage of this functionality.That said, there is Amethyst-specific functionality that we would like to add in the future (e.g. default registration of Amethyst components and resources, showing the state machine stack, showing state event history, etc.). As such, it would likely make sense to split this project into two crates: One that provides specs-compatible functionality, and then continue to build the amethyst-editor-sync crate on top of the specs-only crate.