simple plugin system for schnack

[gka]

This PR refactors all of our currently supported authentication and notification methods into plugins.

The plugins are for now still part of this repo, but in theory they could already live in separate npm packages (and probably should be moved out soon as some might come with have hefty dependencies)

Plugin configuration

Plugins can be defined and configured via the new config.plugins section. To enable the twitter authentication and slack notifications, one would set the plugins config to this:

"plugins": {
    "auth-twitter": {
        "consumer_key": "xxxxx",
        "consumer_secret": "xxxxx"
    },
    "notify-slack": {
        "webhook_url": "xxxxx"
    }
}

Plugin loading

In this PR plugins are loaded (= required) using the loadPlugins function. The function checks whether a plugin exists in one of two locations:

• the src/plugins/${pluginId} folder inside the Schnack repo, and
• a npm package called schnack-plugin-${pluginId}

As mentioned above, we should probably at some point move all "core" plugins into npm packages at some point to get them out of our package.dependencies.

The loadPlugins function is currently evoked at two occasions: in src/auth.js and in src/notify.js (formerly known as src/push/index.js).

There are two entry points that plugins can currently use: auth and notify.

Plugin interface

As said, the plugins are being loaded at two locations, and each is only regarding plugins relevant to the part of Schnack where it's being loaded. In src/auth.js we are only invoking plugins that define the auth() hook, while in src/notify.js we only invoke plugins that define the notify() hook.

So while at this point, all auth and notify plugins are separate, in the future there could be plugins that handle both authentication and notification.

The hook functions auth() and notify() are really only passing some internal variables to the plugins (which cannot easily require them if they live in a separate npm package). This separation between the Schnack "core" and the plugins is meant to discourage ugly hacking and dependencies on internal helper functions etc. Essentially, whatever we're passing as arguments through these two hook functions become part of the new "public" API of Schnack and changes to those will potentially break backwards compatibility.

Example plugins

I already ported all existing auth and notify methods into plugins so you see plenty examples. Here's how the slack notification plugin looks like. It uses the events object to observe new comments and then send http requests to the Slack API.

const request = require('request');

module.exports = {
    notify({ events, config, page_url }) {
        events.on('new-comment', event => {
            try {
                const post_url = page_url.replace('%SLUG%', event.slug) + '#comment-' + event.id;
                const comment = event.comment
                    .split(/\n+/)
                    .map(s => (s ? `> _${s}_` : '>'))
                    .join('\n>\n');
                const text = `A <${post_url}|new comment> was posted by ${event.user.display_name ||
                    event.user.name} under *${event.slug}*:\n\n${comment}`;
                request({
                    url: config.webhook_url,
                    method: 'post',
                    json: true,
                    body: { text }
                });
            } catch (error) {
                console.error('Error sending slack notification:', error);
            }
        });
    }
};

[sto3psl]

The script will crash if plugins is undefined

[joeshub]

just curious about the timeline for this, is this still under consideration?