Idea: Create a "static plugins" system like Bevy to create a "build your own editor" ecosystem

[nicholastmosher]

Firstly, thank you for Zed, it's been awesome! I've been reading the codebase because I find the architecture very interesting, especially the way that GPUI uses a global context pattern. I've recently become very fascinated with this pattern, and the other most notable place I've seen this used is in Bevy.

I wanted to point out that it seems to me that it would be possible (maybe even easy) to invert the current API into a "static plugins" style like Bevy has. I think it would be wonderful if it were possible to capture 100% of Zed's functionality into plugins in this way, as it would allow for people to create a third-party ecosystem of first-class functionality for Zed.

I'm imagining a world where folks can publish crates that act as "GPUI plugins" and that Zed could be wrapped up as a starter bundle of plugins, similar to how Bevy has a DefaultPlugins that installs the fundamentals like a renderer, etc. I think it would be great to be able to do something like this:

use gpui::*;
use zed_something::ZedPlugin; // Bikeshed the crate name

fn main() {
    gpui::App::new()
        .add_plugins(ZedPlugin::default())
        .add_plugin(SomeCrazyThirdPartyExperiment::default())
        .run();
}

Additionally, since Zed/Gpui is very dynamic and uses type lookups so much, it seems to me that it'd be easy to compose plugins, so that third party plugins can become the basis for other third-party plugins, etc.

Today, all of the modules that install themselves into the global context do so in zed's main, alongside other code for setup that currently isn't encapsulated in an init function. If all the setup code for zed could be extracted into fn init(&mut App) functions, that could serve as the foundation for the "batteries included" plugin/s. For reference, Bevy's Plugin trait looks (roughly) like this:

pub trait Plugin {
    fn build(&self, app: &mut App);

    // ... plus other game-engine specific stuff
}

This is effectively exactly the same as what the init functions are doing today in zed, but by putting it on a trait like this and adding an API to App itself like .add_plugins(impl Plugin), it would effectively "invert" the installation of functionality into the app. The biggest reason I bring this up is I wanted to hack on adding something to Zed but found that in the current structure I needed to fully fork the project and mess with zed's own main function.

---

Anyway, I wanted to open this discussion because I feel like this could help to snowball Zed's ecosystem, after all look at just how many plugins exist for Bevy, IMO it's one of the most collaborative ecosystems in Rust because it has this ability to compose plugins. I wanted to check with others if this is something that would be welcome as a contribution before setting out on trying my hand at it.