Sails.js v0.9 plugins proposal

plugins_proposal.md

A Modest Proposal: Hooks

Sails.js v0.9: Release Cantidate for 1.0

Philosophy

• The question of what "belongs" in a framework is complex, and depends on your use case. A better question is "what are the defaults?" By pulling all of the current features of Sails into plugins, and then including them by default, we provide full customizability (the possibility of disabling just about everything) without sacrificing all the conveniences Sails developers are used to.
• Plugins make it easier to contribute, and make modifying the core a much less scary proposition.
• Node.js is quite minimalist, and super awesome. Let's take a leaf out of Ryan/Isaac's book!
• Community plugins are fantastic, but to ensure quality, plugins will only be listed on the Sails website/repo when they've met some basic quality assurance testing.

How It Works

When an app starts up, after the core components load, the initialize method is triggered for each of the configured plugins. Plugins can tap into events emitted from Sails, and hook into other parts of the app bootstrap process that way.

Plugins also have access to the Sails CLI, if developers choose to configure their installation to use them. The cli:new, cli:generate, and cli:build events are automatic, plus you can add your own command-line hooks.

Best Practices

If a plugin provides configuration options, it should hook into the Sails CLI to generate them for new projects on sails new. It should also declare the options in its plugin.json file.

If a plugin adds routes, it should declare them explicitly in its plugin.json file.

If a plugin adds middleware, it should declare them explicitly in its plugin.json file.

If a plugin expects a special directory/files to exist at the app level, it should register that with the Sails module loader so the path is fully configurable for end users. The plugin should also create the directory on sails new.

More to come!

I like how the components ember.js. It is important to be able to customize. I think it makes sense to write in es6 with babel.

for example:

/api/plugins/waterline-plugin/collection.js

import CollectionPlugin from 'waterline-plugin/collection';

class Collection extends CollectionPlugin {
    loadDocument (doc) {
        ...
        //Code here
        ...
        return super(doc);
    }
}

export default Collection;

/api/plugins/waterline-plugin/waterline.js

import WaterlinePlugin from 'waterline-plugin';
import Collection from './collection';

class Waterline extends WaterlinePlugin {
    constructor (...arguments) {
        this.Collection = Collection;
        return super(...arguments);
    }
    afterLoad () {
        ...
        //Code here
        ...
    }
}

export default Waterline;

@mikermcneil, what do you think?