Allow for complex development with multiple plugins or themes
ChrisWiegman opened this issue · comments
The way I've allowed for first-class plugin and theme development currently is a start, but it breaks down quickly if working on multiple related plugins or themes such as a parent/child theme combo or multiple related plugins such as is found in complex sites.
Overview
I think this can be overcome with the concept of multi-plugin/theme sites. Instead of mapping a single plugin or theme we will still start the site from a single plugin or theme but allow for multiple local plugins or themes to be mapped back in.
For example, the local .kana.json file could include localPlugins and localThemes arrays. To maintain portability these array would specify sibling folders to the main kana folder that would be then mapped as a plugin or theme. Should the folders not be present we could simply throw a warning or add a strict flag to fail completely on load.
Example
Let's look at this a bit deeper. Say I'm starting my site from a my-super-plugin folder in my Documents folder on my local machine. My-super-plugin is great on its own but works better with a sidekick so I am also building a my-super-sidekick plugin and I would like to work on them together.
In this case we could solve this by starting the kana site from my-super-plugin like normal and creating the .kana.json file with my-super-sidekick in localPlugins. Kana would then look in the Documents folder (it's the parent of my-super-plugin) for a folder called my-super-sidekick and, if it exists, map it as a plugin in the site. If it doesn't exist it would throw a warning or, if we implement a strict or similar flag on start, could fail completely preventing the developer from wasting time.
Advantages
This would allow for multiple projects to be worked on at the same time with shared logs and a shared IDE environment. For complex sites and other work this will allow a developer much easier access to see how a change on one plugin or theme affects another under their care.
Possible Issues
While I think this is a solid approach, I do have a few concerns.
- Could this cause an issue if the developer has something named in the parent folder that would conflict? I don't think this could be a security issue anymore than anything else but it is something we should look at deeper.
- This could be a bit wonky in practice as the developer would have to make sure they're starting from the same place every time or using the appropriate
nameflag. A workaround would be to simply have akana.jsonin each related project that would treat its folder as parent but that may still be a bit confusing. A possible solution might be to somehow record alllocalPluginsandlocalThemesand respond if the user tries to open one outside the main project. I think this latter approach is probably more complicated than its worth but it is a possibility, I think.
Implementation
I think this would start by updating siteConfig to handle localPlugins and localThemes in the same manner to the current plugins option. From here we need to expand getMounts to make use of the arrays with the proper warnings/etc. Note this is just spitballing here, though, and doesn't account for number 2 in Issues above.
Tagging @coderaaron here for review and thoughts
Makes sense, the only thing I was thinking (and might be for a future version) is having a ‘pluginFolder’ setting that would allow you to set the location of the local plugins, but haven’t really had time to consider all the aspects of that option
Also, does the ‘theme’ song currently exist (ala the ‘plugin’ setting)?
There's no "theme" option in the file... might not be bad to add one as long as it doesn't conflict with the theme flag.
I think that's what you're asking?