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!

This would be awesome cant wait!

has this feature been implemented??

One of the biggest problems I see facing SailsJS is the abundance of generators. Generators are great when they create very small files, but some generators create 100-line files. This is a problem because now the burden of maintenance is on the user instead of the maintainer of the generator. I think plugin support is very important for this very reason.

@kvermeille @Beardtree @Lujaw @albertosouza

This is a problem because now the burden of maintenance is on the user instead of the maintainer of the generator.

I guess the idea is that if you don't like the way a generator works, you can fork it and customize it to fit your needs (i.e. the more generators there are, the easier it is for folks to take over small projects- like the jade generators, for instance). Frankly, it's unmaintainable for the core team and I to maintain everything, even with the help of great PRs, etc-- a big part of the idea with making generators small and simple is to hand control over low-barrier-to-entry points for new contributors.

but some generators create 100-line files

hmm- which ones do you mean?

I think plugin support is very important for this very reason.

Tell me more?

Thanks everyone!

BTW- you can make custom hooks now in v0.10 (and actually even in 0.9 for that matter)-- @uncletammy is working on some docs on the subject

Very keen to see those docs !

Very excited about this feature.

I'm coming form Laravel and have been building packages with composer. I've found that workflow to be easy to work with.

Can't wait to see more on this.

@Zyther it's currently implemented in v0.10 :)

So this was something, but found my answers via sails console. It's loaded with information

I looked at the code which is definitly well organised in 0.10 version, vert gold job
Just few question about hooks and module loader:
Hooks' objets are only used for boostraping, use only sails défaut folders, do notre expose any method (like a add(data|file|directoires) méthod to dynamicly add new controllers, modèls ...). It is on thé roadmap or do you think that such functionalities must je provided by users hooks even for standards objects ?
What is the idea behind the centralisation of 'loadhookobjects' méthodes in module loader ? They should be private fonctions in hooks definition because only used during the hooks' objectb init. Is it the beginning of a global serviceManager ?

where are plugin docs/examples?

Looks like some documentation is here https://github.com/balderdashy/sails-docs/blob/master/concepts/extending-sails/Hooks/customhooks.md

I believe examples/doc/tuto would be great there, but the one provided by @leejt489 helps a bit indeed.
And @mikermcneil yes, I think you should create a default folder in api/hooks with some README.md.

@uncletammy is working on some docs on the subject

update on this subject: http://www.thedotpost.com/2014/11/mike-mcneil-pulling-the-plug

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?