A plugin system

[drublic]

I think we need a better plugin system for INIT. Currently we state:

You can add this plugin to INIT by copying over the file config/plato.js to tasks/options and run npm install --save-dev grunt-plato.

We could utilize Bower to install plugins which does not resolve the problem that a user needs to install the npm repo. But we could easily detect plugins within all components beginning with init- and use the JS file in config or task to require in the Gruntfile.

Another problematic point is configuration for these plugins. What if you need another directory within your repository? This means there needs be an extendable configuration structure.

More problems: Some tasks should be extendable by plugins. As for example watch in the case of Livereload.

Any more suggestions?

[anselmh]

This is a good idea generally. I really like to have a solid working plugin system for INIT.

I am not sure if using bower for plugins would be the right thing. It would be great if he'd had these plugins as options during install of INIT so you can install INIT already with the given (as parameters in CLI) plugins…
Requiring prefixes to fetch them is generally a good idea.

Config is a problem which affects our current structure. I think we need to think how we can modify the whole setup and config structure to be easily extendable.

[kahlil]

I think the best solution for this problem are Yeoman sub-generators. The sub-generator can easily take arguments, process a file with variables and copy it to somwhere and then execute npm install grunt-something on the shell.
The only other option I see here is a gruntplugin doing the same thing. But sub-generators are perfect for this IMHO.

[kahlil]

So this is how the sub-generator call could look like:

yo init:plugin-plato "someargument" "anotherargument"

[sergiopvilar]

I think that plugins can be installed through a prompt menu of only one sub-generator, I don't know, is just a idea.

For example:

yo init:plugins

Wich plugins you like to install?
[x] Plugin1
[ ] Plugin2

[kahlil]

Yes that's a good idea for the project initialization. But we also need sub-generators for after the project has been initialized.

And for sub-generator configuration I would like to see if sub-generators can use prompts as well. I guess it should work.

[anselmh]

Thanks for your input, @sergiovilar @kahlil. This is very useful. I think it is the right way to go with yeoman sub-generators somehow.

[kahlil]

Just a FYI I just saw this: http://codeactual.github.io/06/02/2013/introducing-grunt-horde.html might be an optional approach...

[sergiopvilar]

@kahlil you are right, for the project initialization sounds good. But in this case we'll write a sub-generator for each plugin or only one sub-generator with options?

[kahlil]

That's a good question @sergiovilar. Needs to be thought through and discussed. I am leaning towards one sub-generator per plugin.

[sergiopvilar]

Today init have few plugins but I'm looking for a possible future, one sub-generator per plugin will cause mess if a lot of plugins is developed

[kahlil]

That's true. So maybe we just make a generator per plugin. and namespace them generator-initplugin-<pluginname> or something like that. Then you don't download all plugins if you just want to scaffold a default INIT project.

[sergiopvilar]

I don't know if this is the best solution but I have no idea to do this.

@anselmh @drublic what you say?

Maybe we can create only one sub-generator in the main generator repository and separated them all into independent modules. In this case, only the main file of the sub-generator:plugin, por example, will include the plugin modules.

[drublic]

So here is a concept for our plugin-system.

In general we prefer a Yeoman sub-generator which is a part of the INIT generator. Most INIT plugins won't require a lot of configuration but if they do they might come with some initial config which might be changed manually.

The tasks for this generator might be something like this.:

• installes plugin task file – naming convention: {taskname}.js in the plugin repo – which is basically copying over the task in the folder tasks/plugins
• runs npm install --save-dev {pluginname} – which is stored in a package.json file in devDependencies in the plugin repo
• adds necessary config options to main project's config.js which are stored in a plugin specific config.js file.

The generator might be called by setting the plugin name as one argument like this:

yo init:plugin {plugin-name}

For the time being the plugin-registry might be the GitHub organization but we might change this later on.

Plugins might utilize INIT's default configuration and extend this configuration within the project with the required config from the plugin's config.js. The configuration within this file must stick to INIT's structure.

Any additional info or stuff that I forgot to talk about? Please let us know!

[kahlil]

Hey @drublic I am not sure if I completely understand.

Do you want the sub-generator to pull plugins from Github or do you want the sub-generator to scaffold out boilerplate for new plugins?

[drublic]

I want the sub-generator to pull plugins from GitHub. Scaffolding new
plugins isn't necessary I think.

On Tue, Jan 21, 2014 at 8:55 AM, Kahlil Lechelt [email protected]:

Hey @drublic https://github.com/drublic I am not sure if I completely
understand.

Do you want the sub-generator to pull plugins from Github or do you want
the sub-generator to scaffold out boilerplate for new plugins?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/67#issuecomment-32827656
.

[kahlil]

Hmm that is not really what the generator does.

We could make a small command line tool that just clones the plugin repo and copies the files to their respective places and work with conventions.

If there is no repo or the expected files are not in the repo => err.

[kahlil]

I just remembered: we can use Bowers programmatic API to install the plugins...
That means either the new cli tool or the sub-generator uses Bower to install a plugin and after its installed does the other operations.

I have to think about this.

[sergiopvilar]

@distilledhype is possible to call bower through a Yeoman sub-generator? I think if this is be possible, we can do this in this way.

[drublic]

Plugin configurations can now be placed in grunt/plugins and will added automatically. We still need documentation for this. Also a Yeoman generator is needed to automate this task.

[drublic]

@distilledhype wrote:

We could make a small command line tool that just clones the plugin repo and copies the files to their respective places and work with conventions.

This is exactly what we should do.

I just remembered: we can use Bowers programmatic API to install the plugins...

Currently we don't want to utilize Bower for these plugins.

I think a decent way would be to clone the plugin to install in a directory, move all the things around and delete the rest of the repo. This would mean that we only need a convention for

1. repo URLs
2. file names
3. directories

Most of this is given:

1. Repos for files can be matched as "use-init/init-" at GitHub. We could later extend this to make it customizable and stuff.

2. I've outlined this above: We need to copy the {taskname}.js file into the folder grunt/plugins, we need to run npm install --save-dev {pluginname} and lastly add necessary config options to main project's config.js which are stored in a plugin specific config.js file.

3. We need a temporary folder to place the repos in. I'd suggest to name it .init-cache. Everything else is stated in 2..

I will now close this issue in favor of an issue in the generator-init repo (use-init/generator-init#20). We should focus work and discussion over there. Thanks everyone of your input.