This repo is intended to serve as an example of how to write an npm package for Reaction that has dependencies on Meteor and/or other internal Reaction API's. The main part of the discussion that is currently needed is around what we will standardize as the official plugin API's. As things are now, dependencies like Meteor, Reaction, Tracker, check, and Match are needed in most Reaction plugins, so npm packages will require some wrapper functions around most (all?) of their API so that they can have their dependencies injected at the time they're registered within Reaction.

For example, most Reaction plugins will need to add Meteor methods to the app and they, at the very least, will require check and/or Match to be injected. That said, my thinking was that we standardize a function like getMeteorMethods that takes dependencies as arguments and then returns an object of Meteor methods that can be passed into Meteor.methods() within Reaction. So maybe that looks something like this...

import { getMeteorMethods } from "@reactioncommerce/some-payment-plugin";
import { check, Match } from "meteor/check";
import { Reaction } from "/server/api";

const methods = getMeteorMethods({ check, Match, Reaction });

Meteor.methods(methods);

The same is true for registering schemas. Most schemas in Reaction have a dependency on check and Tracker, so we'll need to do something similar there. Maybe something like...

import { registerPluginSchemas } from "@reactioncommerce/some-payment-plugin";
import { check } from "meteor/check";
import { Tracker } from "meteor/tracker";

registerPluginSchemas({ check, Tracker });

The above example would work just like using registerSchema within Reaction, but it allows us to inject check and Tracker at the time of schema registering.

There are a bunch of similar situations like this that need to be talked out (for example, registering /using UI components), but the above samples were the easy examples. Perhaps a good first step here would be to start making a list of dependency injection wrappers that are going to be needed for most plugins. Then anything that is more plugin-specific can be documented within each plugin.

cc: @zenweasel @spencern @aldeed