Plugins

Files & Directories in a plugin's directory NOTE: $PMS_PLUGIN = name of plugin, ex "vim"; $PMS_SHELL = shell being used, ex "bash", "zsh", etc.

bin/ Included if the plugin has any binaries or scripts included
env contains environment variables used by your plugin.
- NOTE: User can overwrite these, reference Environment Variables
$PMS_PLUGIN.plugin.sh contains generic shellcode
- Best Practice: This file should contain aliases
$PMS_PLUGIN.plugin.$PMS_SHELL will contain specific code for the shell being used
install.sh runs only once when a plugin is enabled using the PMS Manager
- Good to let the user know information about your plugin and to include links to the User Documentation
- Can be used to prep the system (enable other plugins, etc.)
uninstall.sh runs only once when a plugin is disabled using the PMS Manager
- Good place to ask the user for feedback on why they are uninstalling the plugin?
- Can be used to revert any files that were previously modified and edited by the plugin
update.sh runs when a user updates a plugin using the PMS Manager or when a user upgrades PMS
- This is a good place to add scripts to auto-update 3rd party tools (composer selfupdate, npm install -g n pm, etc.). However, there must have a setting that allows the user to turn this off.
- Could also use this command for various garbage collection tasks

NOTES:

User Documentation will go in the docs/ directory in the project's root directory for each plugin
- See https://github.com/JoshuaEstes/pms/tree/master/docs
Developer Documentation should go in the code and can be included in docs/ or the plugin's docs/ directory

Loading

When a user opens a new session, it will load all the plugins and plugin files will be loaded in the following order:

When a user runs pms plugin enable $PMS_PLUGIN, files will be loaded in this order:

When a user runs pms plugin disable $PMS_PLUGIN, files will be loaded in this order:

When a user runs pms plugin update $PMS_PLUGIN OR pms upgrade, files will be loaded in this order: