Plugins

[arctic-hen7]

Is your feature request related to a problem? Please describe.
Right now, there's a large number of modifications to .perseus/ (which all require ejecting) that could be modularized.

Describe the solution you'd like
Perseus should have a plugins system with three types.

Type 1 plugins should provide functions that can be provided with extra information through define_app!. These functions will the be executed at various places in Perseus' engine. For example, a plugin could be created with this system that would add new routes to the inbuilt server, adding a GraphQL API with almost no configuration and no separate systems.

Type 2 plugins would be more powerful, being able to modify files arbitrarily in addition to providing type 1 capabilities. An example use for this would be appending size optimizations to .perseus/Cargo.toml.

Type 3 plugins would be the most powerful, as they would have their own entirely customizable .perseus/ directories. Further, they'd issue instructions to the CLI that would set new commands to be run for different Perseus commands. For example, they might instruct perseus serve to also spin up extra servers and a database in parallel. These would be read from a specially named file in .perseus/, and this would be done by stages. Then, an extra stage of completely custom executions could be added, which would preserve the CLI's own loaders and progress reporting system.

Describe alternatives you've considered
Manual ejection in all cases, but this is very tedious, and doesn't lend itself to a highly customizable and collaborative open-source ecosystem.

Additional context
Types 1 and 2 should be ready for v0.3.0 when it goes stable (meaning more beta releases), but type 3 will be reserved until after that. However, CLI instructions would be very useful for ejections already, and that should be included.

This issue will track general progress for all aspects of the plugins system, which will improve Perseus dramatically by providing the customizability of v0.1.x with the convenience of v0.2.x and the power of x0.3.x.

• Add support for functional plugins
• Add support for control plugins

[arctic-hen7]

Designing this, I can see a great deal of things that should be able to be modified by functions, but that aren't compatible with multiple plugins. For example, a plugin that modifies the call to sycamore::render_to would be type 1, but wouldn't be compatible with any other plugins, as it takes full control there.

So, there should be some functions that should be restricted to type 2 plugins.

[arctic-hen7]

We also need better names than types, because they will not be remembered well. Here's a proposal:

• Functional plugins (always compatible with each other except in niche cases)
• Control plugins (one plugin takes control of one or more critical functions, replacing the default behavior altogether)
• Engines (custom .perseus/ directories)

This naming clearly separates the idea of plugins from custom engines, which it doesn't really make sense to even call 'plugins', they don't plug in, they replace the socket. In light of that, engines should have their own tracking issue entirely.

[arctic-hen7]

Okay, the fundamentals of the plugins system are ready! There aren't that many actions yet, but they should suffice for most use-cases. Anyone who wants further actions is more than welcome to open further issues, and I'm happy to oblige. I'll add support for custom CLI instructions next, and then I'll build a few plugins to see how the interface works in the real world.