Create a plugin to be able to require non chainy namespaced modules

[balupton]

Considering we can now do module.exports.extension = {}, it would be nice if we could require standard npm modules too. I'm thinking this could be a plugin that is added to the chainy package. It would allow us to do the following:

require('chainy').create().require('lodash.flatten set log')
    .set([1,[2,3],4]).flatten().log() // [1,2,3,4]

The potential for this is to finally stop having framework specific plugins being created, instead we can just update existing modules with the required configuration, that then works in different frameworks.

It would also allow us to create our own cli tools using chainy, then have them themselves be chainy plugins too, without the chainy-plugin- namespace. E.g. geojson-github-communities bevry docpad chainyjs could be a CLI tool, but also a chainy plugin without the need for chainy-plugin-geojsongithubcommunities. Instead, you do chainy install geojson-github-communities, and in chainy .require('geojson-github-communities') and it works as expected. Probably attempting for a chainy-plugin first, and then falling back on without one if not.

One side issue here, is that things like chainy-plugin-map etc, use this.create(), now this inheritance is important as it allows for greater debugging due to the tracking of children and parents. If we were to do require('chainy-core').create() it is now true that the plugin would be standalone, but it would lose it's inheritance abilities. Perhaps what we need is this: require('chainy-core').create().inherit(this), which then sets up the parent etc, while maintaining standalone abilities.

[balupton]

This may become part of the core I think, as it is such a fundamental use case. Or plugin, eitherway.

If this becomes part of the core, we will need to think about the default type. For instance take the example case, lodash.flatten has the implied extension type of action, however it is never explicitly set. Adding a default type can be quite problematic.

---

Another consideration is breaking the autoload plugin, how will it know what to require? Perhaps it can scan the package.json files of every dependency for a chainy-plugin keyword, but that requires package author cooperation. However, this is probably better than the current approach.

---

Perhaps we need to do something like requireExtensionsOfType('action', 'lodash.flatten'), but then it puts the grunt work on the user, which isn't cool.

[balupton]

/cc @JedWatson — keen to get your feedback on this

[pflannery]

I was wondering if http://jspm.io/ would suit this as it lets you load from github, npm, commonjs and it's own repo. Its also server\client agnostic so could be a good solution.