Open IQuick143 opened 1 week ago
I would love to see this! I believe someone made of a demo of this a few months back, it integrated with Rustdoc's metadata output directly.
You may be able to use Miri combined with an introspection plugin, but I've never done such a thing before.
As @IQuick143 mentioned on Discord, we could also have a CLI version of this. E.g.:
bevy list [components|systems|resources|events|plugins|etc..]
For systems this may be challenging:
fn foo() {}
are valid systems, so type signature isn't enough and you need to look for .add_systems
specifically..add_systems
calls may be hidden behind feature flags, dead code, plugins that are conditionally added, etc. at runtime. It's probably fine to assume that xyz
is a system if it's in an .add_systems
call, even if that call never runs, though.One pathological example:
let i = foo;
let j = bar;
app.add_systems(if x > y { Update } else { PreUpdate }, if y > z { i } else { j });
I agree that systems are rather challenging.
Considering anything that goes into .add_systems()
to be a system seems good to me, although it does have drawbacks, and it's true that we can't always decide what system goes into what schedule (although I have not seen anyone write code like that pathological example).
I think we just need to add some sort of override/hint system, so that users can explain their pathological examples if they do occur.
Observers and one-shot systems could IMO get a different section in the docs, but documenting these would also be important.
What?
I think it would be nice to have a tool that would be able to generate Bevy (ECS) oriented documentation from project source files.
Some things this documentation should (help) answer:
Some things this documentation alone is not intended for (some of these could be done by integrating with
cargo doc
and linking to there):Why?
Collecting the information about a bevy project involves many many declarations as well as many App method calls. (plugins (method bodies), Components (declarations and attributes), Resources (declarations, attributes and App registration), systems (function signatures and App registration), Events, and so on...) Bevy projects are recomended to be highly modular and split up, which is in many regards good, but it means that all this information becomes spread out across many files, and worse (in my experience) it becomes dilute. (ex: you need to read the system signatures, but the system bodies are irrelevant to you.)
Even if it's reasonably easy to find what you need by following Type information breadcrumbs via go-to-reference and go-to-declaration, this involves a lot of jumping around, and in my experience does not lend itself to learning the overall structure of the project.
How?
I don't know how difficult it would be to implement, I imagine the biggest challenge is reading and collecting all the required information about how the App is constructed (TODO: What if the user has no bevy_app, can we still learn useful information from things like Schedule::add_systems?) Many other pieces of information should be relatively easy to parse (such as Component declarations and their attributes.)