bevry/docpad — Issue #135: docpad npm support for exchange
Author: balupton
Created: 2012-02-14 15:37:38+00:00
State: open

# 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).