matthewmateo
commented
6 months ago Sorry I keep meaning to get to this but I'm wrapped up with other things, will respond fully once I get some time to explore the idea some more. Definitely want to add plugins though, I imagine it'll be a game-changer for what people can do with the tool.
I've been dying to add features to Primo like:
But that's just my ideas and would probably bloat the project. Plugins is the way to go. There are some things we need to decide before moving forward:
Plugin Installation
It's pretty much standard that whoever uses Primo forks it first, that doesn't apply to the builder though. So the easy option to have each user add his plugin packages in his Primo fork means that whoever wants to use just the builder won't be able to use plugins. Forking both the builder and the server is pretty inconvenient IMHO.
My best idea is to standarise the naming of the plugins (e.g.
primo-plugin-*) and have apreparescript that installs them via environment variables during deployment. OFC the plugins need to be published in npm.Plugin Integration
Vite should handle importing the plugins at build time, I see no reason for using dynamic imports in the app code.
Integration Points
Register functions (or hooks if you're familiar with Wordpress) must be added throughout the codebase wherever we want that functionality extended. This WILL require some refactoring.
Plugin Structure & Documentation
It is very important to have clear guidelines on how a plugin should be written, what it can and cannot do. A skeleton plugin is a nice starting point for most people. Perhaps have different structure per plugin type, e.g.:
Tests and error handling
People will write trash plugins, use same export names, or simply Primo updates might break them. We should force basic tests and give proper error descriptions. If we were to load the plugins dynamically during runtime we could also skip loading erroneous plugins, but I'm more of a fan of build time.