While trying to make a keybinding config, I came across the issue that bevy_input::KeyCode doesn't implement Serialize or Deserialize and there is no feature to do so. I think it would be nice to have support for serde (behind a feature) for types which users of bevy may want to serialize, such as KeyCode and MouseButton.
Yeah this makes sense to me!
Keep in mind there鈥檚 also https://github.com/not-fl3/nanoserde and https://github.com/dtolnay/miniserde.
I think its worth giving the "minimal serde" implementations a fair shake, given how much they improved macroquad compiles. But I dont think we'll see similar clean compile time improvements without fully removing syn + quote dependencies from the tree. They run pretty deep in many rust crates, so this will likely be very hard. In general, while serde does have a compile time cost, it is the ecosystem standard and it feels "worth it" to be aligned and have the additional flexibility it gives. We also heavily rely on erased_serde for bevy_property. But if they can yield significant compile time wins, then I'm definitely open to using them.
Short term, I don't see much harm in adding additional serde impls, given how prevalent it is in our codebase (and our dependencies' code bases).
For compile times you may want to investigate cargo watt as a way to pre-compile the proc macros to WASM, preventing the need to compile them when building bevy.
Most helpful comment
I think its worth giving the "minimal serde" implementations a fair shake, given how much they improved macroquad compiles. But I dont think we'll see similar clean compile time improvements without fully removing syn + quote dependencies from the tree. They run pretty deep in many rust crates, so this will likely be very hard. In general, while serde does have a compile time cost, it is the ecosystem standard and it feels "worth it" to be aligned and have the additional flexibility it gives. We also heavily rely on erased_serde for
bevy_property. But if they can yield significant compile time wins, then I'm definitely open to using them.Short term, I don't see much harm in adding additional serde impls, given how prevalent it is in our codebase (and our dependencies' code bases).