idea: plugins in component.json

[ianstormtaylor]

was thinking it would be cool to have plugins listed in component.json metadata so that places like component.io can pick them up and list them semantically. would just be a straight array:

{
  "name": "model",
  "plugins": [
    "ianstormtaylor/model-defaults",
    "yields/model-indexdb",
    "segmentio/model-localstorage"
  ]
}

maybe there's a better name than plugins

[timoxley]

but what are "plugins"? how do they differ from "components" i.e. "dependencies"

[ianstormtaylor]

haha yeah i was gonna say an argument against it is that it's old-world thinking. but at the same time, i feel like certain strict APIs like model and builder.js will always have components instead of just any old plug and play thing.

unless you're literally taking about the outcome, in which case it doesn't do anything in the build process. its just metadata to link semantically to repos that are plugins of the current one (like keywords, author, etc). they dont get built in or anything, which would make huge files if you used dependencies for this case

[ianstormtaylor]

sorry, to be more clear, plugins are things you extend the functionality of a component with, usually with a use method, like builder:

var Builder = require('builder')
  , jade = require('component-jade'); // plugin

var builder = new Builder(__dirname);
builder.use(jade);

or model:

var model = require('model')
  , defaults = require('model-defaults'); // plugin

var Person = model('person')
  .use(defaults)
  .attr('age', { default: 0 });

the reason for wanting it in component.json is so they can be displayed along with the main component in directories, otherwise they are hard to find. and it also increases the value of the main component by a lot if its got an ecosystem of plugins.

[buschtoens]

Maybe it should be the other way around. The plugins' package.json contains something like "extends": {"ianstormtaylor/model": "~1.0"}.

​This way the main package doesn't need a push for each and every new plugin.

On Tue, Jun 4, 2013 at 5:32 AM, Ian Storm Taylor notifications@github.com
wrote:

sorry, to be more clear, plugins are things you extend the functionality of a component with, usually with a use method, like builder:

var Builder = require('builder')
  , jade = require('component-jade'); // plugin
var builder = new Builder(__dirname);
builder.use(jade);

or model:

var model = require('model')
  , defaults = require('model-defaults'); // plugin
var Person = model('person')
  .use(defaults)
  .attr('age', { default: 0 });

the reason for wanting it in component.json is so they can be displayed along with the main component in directories, otherwise they are hard to find. and it also increases the value of the main component by a lot if its got an ecosystem of plugins.

Reply to this email directly or view it on GitHub:
#346 (comment)

[ianstormtaylor]

yeah that's definitely much better if they're all crawled into one dataset, which i guess isn't too much to expect. gets over the annoyance problem of maintaining one to many plugins

[buschtoens]

Great, now we only need to find a suitable name for this property and @visionmedia's okay.

Is there a better word than "extends"? It too much reminds me of subclassing and prototypal inheritance (which is also an interesting idea for compinents btw).

On Tue, Jun 4, 2013 at 5:57 AM, Ian Storm Taylor notifications@github.com
wrote:

yeah that's definitely much better if they're all crawled into one dataset, which i guess isn't too much to expect. and definitely gets over the annoyance problem of maintaining one to many plugins

Reply to this email directly or view it on GitHub:
#346 (comment)

[jonathanong]

Basically peer dependencies?

[buschtoens]

Well, now that you say it. Yes. :D

On Tue, Jun 4, 2013 at 6:17 AM, Jonathan Ong notifications@github.com
wrote:

Basically peer dependencies?

Reply to this email directly or view it on GitHub:
#346 (comment)

[ianstormtaylor]

haha yup, peer dependencies is exactly what i was trying to say. although hopefully we can shorten it to peers, or extends or something else without camel case

[jonathanong]

prefer if we keep it peerDependencies instead of creating an entirely different spec. it'll also be easier for new component users coming from npm to understand.

[ianstormtaylor]

peerDependencies -> peers would be pretty equivalent to devDependencies -> development imo

[jonathanong]

oh god i forgot they did that. i guess that point is moot then.

[tj]

haha yeah sorry I had to change devDependencies it bugged me too much :D. Sounds decent though

[buschtoens]

So, I take it. The idea in general is accepted. However a good name has to be found. peerDependencies sucks; shortening it to peers is better. However peers doesn't really fit. The components listed under peers aren't peers to the plugin. They are more of a host (still this doesn't fit quite right).
I kinda like extends as the plugins really extend their hosts. Yet extends is commonly used for inhertiance. So we can't really stick to that either.

As soon as we have a name we can start implementing in the spec, component-info and component.io.

Any good ideas? Maybe @visionmedia can tweet something about it; he has a decent amount of followers.

[ianstormtaylor]

some other names: augments, supplements, enhances, modifies