docpad npm support for exchange

[balupton]

Value

The value will be that we can then have installed by default, installed by user, and enabled/disabled extensions. The user can then publish their own extensions and they will be available to everyone without docpad having to do a new release. E.g. docpad plugin pubilsh and docpad plugin install [name]

Implementing

Registry

Public NPM Registry - no

We could put the docpad extensions into the public npm registry, however I fear this will pollute the public npm registry. And be a lot harder for bevry to manage. So this is not an option.

Private NPM Registry - yes

It looks like it will need two registries, one for plugins and one for skeletons - as the searching support is not that great in the built in registry search. However, we could always write our own search interface to the registry - though this could be quite hard.

Installations

Inside package.json

Extensions could be listed inside the package.json files, however as they will be in their own registry we will have to reference them via their tarball location instead of by version number. This shouldn't cause that much impact.

Inside docpad.json

Having extensions listed in their docpad.json file, which is then treated like a packge.json file will be good, as we could reference version ranges for the extensions. However, it means that docpad will have to trigger installations of these extensions on deployment (it may not be able to - e.g. cloud9).

Distributing

Plugins are installed to DocPad Installation

When a plugin is installed it will be installed to the docpad installation. This will make it available for us to use it in new websites when offline (just copy our docpad installation's copy across).

Plugins are installed to Website Installation

We also need a way to add the plugins that the website actually uses into the website's package.json. This will have to work like so:

• Whenever docpad plugin install [name] is called within a website, then it is added to the website's package.json
• This should never happen if the plugin is a default plugin.
• Load plugins via docpad.requirePlugin(name) if it fails, we tell the user they probably want to install that plugin.

[balupton]

Implemented in DocPad v5.0