Plugin support discussion

[fwip]

It might be nice to have a structure for adding plugins to the core hyp CLI tool.

This could have a couple of benefits:

• Lower friction to try new plugins
• Enabling user customization and development
• Trialing features before getting into core

With a couple of corresponding cons:

• Less guarantee of plugin "interoperability"
• More confusing UX when multiple competing plugins exist
• Plugins are often more likely to "bit-rot"

Questions to address:

• How does a user discover a plugin?
• How do you author a plugin?
• How do you "set up" a plugin?
• What level of integration is appropriate? A "looser" or more relaxed integration makes the plugin author do more work, while a "tighter" integration may constrain the plugins that are possible.

[fwip]

As a discussion prompt on the levels of integration that are possible, I've written up my understanding of a few existing plugin systems:

Git

Git takes a very relaxed integration standpoint with regular git commands. If a user wants to add git my-cmd foo bar, they create a script git-my-cmd and put it on their PATH:

#!/bin/bash
foo=$1
bar=$2
echo "doing something with $foo and $bar"

Git also uses this pattern in more constrained ways, like git remote helpers. The git-ssb plugin uses this (I believe), installing a command called git-remote-ssb, which transparently augments git to be able to handle repositories hosted on Secure Scuttlebutt.
Remote helpers executables must correspond to a specific API (documented in the man page), accepting a fixed list of instructions - some mandatory, and some optional.

Both of these approaches involve git interacting with an executable (language/framework agnostic), and managing/discovering these plugins is done entirely separately.

asdf-vm

asdf is roughly a "tool version manager" that takes a similar sort of approach to handling plugins. These plugins do not add additional top-level commands, but rather, extend the capabilities of the asdf software, so that it is able to manage the version of new tools. (e.g, the nodejs plugin allows asdf to manage node versions).

Like git remote-helpers, asdf communicates with the plugin through executable files. Plugins must provide [a fixed set of executables](https://asdf-vm.com/#/plugins-create, named by convention, that behave in specific ways, as well as optional scripts.

However, asdf does provide plugin management baked into the tool. Adding, removing, and updating plugins can be handled with asdf plugin [add|update|remove] nodejs - supporting both a curated set of plugins, or plugins from arbitrary git repositories.

vim

Vim plugins are simply VimL files put into the right places in special config directories, with some best practices that you may adhere to. It's basically the equivalent of eval(fs.readFileSync('myFile.js')) - powerful because you can access and manipulate any context from the main application, but dangerous. There is no integrated repository or management of plugins*, and the community has produced an abundance of tools that have converged on using vim-scripts and Github as centralized distribution points.

*Vim now has a native package loader, but is not widely used.

(Oh-my-zsh)[https://github.com/ohmyzsh/ohmyzsh/wiki/Plugins] is another tool with a plugin system that just sources (evals) any plugins specified by the configuration. Like asdf, it handles "core" plugins within the tool itself, and also allows installation of arbitrary other plugins.

This post is probably too long at this point, and I know that other plugin management solutions exist within the node ecosystem, but I am less familiar with them.

[pfrazee]

I think this is pretty reasonable, especially given that hypercore has such an open potential for custom data structures. I like the git design -- very straightforward. What do yall think, @andrewosh and @mafintosh?