Consider generalising Stripes' notions of plugin

For the Codex-search UI module, we want to display full records from multiple sources (initially the local inventory and the KB). Rather than coding display logic for these different kinds of records within the Codex UI, we want to use existing display logic from the modules that already deal with this kind of data – https://github.com/folio-org/ui-inventory/ and https://github.com/thefrontside/ui-eholdings

In the shortest term, we will do this simply by linking to those modules' full-record displays. That is the task of UISE-9 and UISE-26. But we want to go beyond that, to displaying full records within the context of the Codex app itself.

To do this, we need a way of sharing the display code between the underlying modules and the Codex module – broadly, the ViewInstance component from ui-inventory and whatever the equivalent is for ui-eholdings.

But how best to do this? We are in agreement that we don't want one UI module (ui-search) to simply reach inside another (ui-inventory) and pluck out a component that it likes the look of. Instead, we want to make this internal dependency explicit by packaging the component to be shared as a plugin. That plugin would then be used both by the module that defines it and by ui-codex.

The question is: how best to associate such plugins with the modules that define them? Up till now, the rule has been that every plugin is its own git module (which we can change fairly easily) and its own NPM package (which will be harder to change). Perhaps the best approach would be to have a single git module (ui-inventory, say) publish two separate NPM packages, ui-inventory and ui-plugin-display-inventory. To make this work, we'd either need to keep the versions of the two packages locked together, or possibly use this lerna thing that Jason's always talking about.