Globally installed extensions

[AljoschaMeyer]

Another fancy feature-idea with really low priority:

What if users could do a global install of an extension, and all vorpal programs would automagically be able to use the commands provided by the gobally installed extensions? I suppose this is doable (or else vorpal-use wouldn't exist, right)? This would not have to be limited to commands, the extensions could just be loaded as usual. This way, global extensions which monkey-patch vorpal would be possible as well.

However, some extensions don't provide out-of-the-box usable commands, e.g. Vorpal-Tour. These should not be automatically included. Maybe differentiate between extensions and plugins?

This would allow really cool stuff. As a user, I could just install vorpal-less and have it in all my vorpal-based applications. I did not look at the architecture of Cash yet, but if the single commands are implemted as extensions, all of these could become globally available as well.

[dthree]

That's a great idea! I would call it a plugin, I agree, to separate it from an extension.

Let's discuss more!

[AljoschaMeyer]

Some further suggestions (and actually some repetitions from the first post):

If possible, writing a plugin does not change at all, just an exported function being passed vorpal and options. Application developers can still depend on a plugin and use it as usual. But if installed gloablly, the plugin is used in all vorpal applications.

Default options: Vorpal would call use for plugins without options. Perhaps default options should be explicitly defined by plugins?

Configuration: While things should just run out of the box, more control for interested users would not hurt. A global vorpal config file could be used to provide custom options to specific plugins, or to turn them on/off.

Conflict resolution: If the npm-package name is used as an identifier, no naming conflicts can arise between multiple global plugins. But a global plugin could be installed which an application depends on and uses manually. Local one should get priority (full control for developer, specific options can be passed etc.)
More problematic are multiple plugins adding commands of the same name. Not sure how to handle this:

• exit with error, refusing to start application until conflict is fixed (i.e. one plugin disabled/deinstalled)
• first come, first serve
• define priorities in config file
• automatically namespace (via nested commands) the duplicated programs
• automatically namespace all plugin-provided commands

Plugin discovery: Every globally installed module with a special npm keyword (e.g. vorpal-plugin) is considered a plugin. This allows things like easy plugin discovery.

Plugin availability: A user running an app does not necessarily know it is powered by Vorpal. How does he kow he can enhance it with sweet plugins? With plugins, it is in the interest of the app developer to tell the users that Vorpal is used. So we should help the developer to do so. Provide an informative website, maybe a readme badge etc.

Powerful: Not just restricted to adding commands, but full modifications on the vorpal object. JS allows pretty much everything, including completely breaking Vorpal. But in that case, one can simply deinstall the plugin. An example for a useful non-command plugin could be an enhanced auto-completion of commands.
To assist plugin developers, vorpal could provide some hooks (or even just events).

Plugin-Bundles: A plugin could simply depend on some plugins locally and use them, globally installing the parent-plugin then gives you all the features from the child-plugins. Still haven't looked at cash architecture, but this pattern seems useful to me.

Apps-As-Plugins: Could an application also export its own functionality as a plugin? Again a pattern that would be cool for cash, the plugin part would add all the linux-commands to any vorpal-application. Then again, just installing it as a cli tool should not directly cause modifications in other installed vorpal programs. So this probably is not a good idea. But instead, a program wishing to export its own functionality as a plugin, could do the implementation in a plugin, and then simply depend on and use said plugin.

[dthree]

I'm really liking this, and agree with each of your points!!!!

Damn. I need more time.