Add support for community tasks

[marcooliveira]

Users should be able to create tasks, and share them with the community. These could be declared as a dependency in the package.jsonfile, and automatically loaded by automaton.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[satazor]

@marcooliveira right now users are able to use other one's tasks with node's require.
Afterwards, we can think in an autoload mechanism to be able to use other one's tasks by id.

What we should need to discuss now is a place where people can "register" tasks. Grunt has it's own organization with a lot of grunt-contrib-* tasks (minify, concat, etc).
Since I'm doing the spoon build, I would like to start creating those in the right place, so they can be reused by other people. Right now, the spoon build has minify requirejs and all those stuff as inline tasks.

[satazor]

I'm also not sure if we should have minify concat and those stuff as built in tasks.
For instance, if one uses RequireJS, r.js already minifies code.

[marcooliveira]

Yes, I see what you mean. We need to get together and properly discuss this. This is a major topic.

[sindresorhus]

Braindump:

• Example of reusable external task
• What should the naming scheme be? automaton-sass? Should there be a keyword (grunt has gruntplugin)? There need to be an gettings started guide or something with some tips an guidelines. People are like sheeps without.
• Grunt had a problem at the beginning with a lot of duplicate tasks (well, still has). How can we prevent that?
• Website should show available plugins. Feel free to fork this: https://github.com/cowboy/grunt-plugin-list
• How should people document their tasks. What should be documented at task level and what should be in Automaton docs?
• Automaton badge? To place in task readme. Would be cool.

[marcooliveira]

Task publishing and discovery

I wonder if the naming scheme is a must. As long as we had a nice guideline for contributing, we could specify a standard tag, something like automaton-task, which would be used to find tasks in npm. We could also use the tags to reduce/mitigate the duplicate tasks issue. Users would be able to perform a realtime search for tasks (both on website and CLI), and the following should be taken in consideration when searching:

• title, description and tags and used in the search
• ranking of results would be done based on string match ranking, curation information (we could boost tasks we feel are really good), community information (download counts, etc)

The repo you provided will be helpful to get this going!

Guidelines

I agree this is a must to help the community contribute.

Documenting tasks

This should also be in the guidelines. Not sure if I understood the question of documenting at task level vs Automaton. Are you referring to some tricks that some tasks might have thanks to utils that Automaton provides, like minimatching? If so, we probably will need to have a separate area in the documentation, with the available utils, and users publishing tasks would just link to the respective section.

Automaton badge

I like the idea. @satazor explained me what that was, and could be a nice way to get some attention from the community, and a nice way for projects to advertise that they have a standardised way of performing typical tasks, like building, scaffolding, etc.

[sindresorhus]

The naming is more about quickly identifying what the npm module is. It also frees up a lot of names. automaton-sass, which would without the prefix already be taken. I think it should be a recommendation, but not a requirement. The keyword should be a requirement though.

and users publishing tasks would just link to the respective section.

Yes, but a template of a task readme would be nice to have so it's fairly standardized.

Automaton badge

Inspiration: componentjs/component#144 (comment)

[marcooliveira]

Totally agree with you. Will take it into account.

🆒 Awesome idea, that badge thing. Definitely including it.

[millermedeiros]

my main disagreement with grunt is that it favors plugins and for me plugins are a bad idea. There is no reason why I task can simply be a function that receives options and produces an output.. using r.js as an example, there is no need for a Require.js plugin:

// pseudo-code
task('foo')
 .depends('setupDirs') // should execute task "setupDirs" before "foo" 
 .options({
    name : 'main',
    out : 'main-built',
    baseUrl : '.'
  })
 .action(function(data, done){
    // data is a mix of static options and stuff coming from cli
    var rjs = require('requirejs');
    var settings = data.options;
    if (data.flags.verbose) {
      settings.logLevel = 0;
    } else if (! data.flags.silent) {
      settings.logLevel = 1;
    }
    rjs.optimize(settings, done);
  });

and I'm thinking of an usage like:

automaton foo --verbose

the foo task takes no arguments but still uses the global flags to toggle the behavior.

gradle have some interesting concepts related to the way tasks works but it's mainly based on inheritance which I think isn't really necessary.

[satazor]

@millermedeiros while we didn't know gradle we share lot in common but with a different syntax. Automaton tasks are formed having inheritance and composition in mind. In 0.2.0, the task you described would have the following syntax:

task
 .name('foo')
 .option('name', 'The name', 'main')
 .option('out', 'The output file', 'out')
 .option('baseUrl', 'The base url', '.')

 .do('setupDirs') // The 'setupDirs' would need to be loaded within automaton, alternatively use require('path/to/setupDirs')
 .do(function(options, done) {
    // your requirejs func goes here
  });

This would run the tasks in order but we will support parallel execution in the future.
The options are defined like this because we want to give the ability to give options a description to print when automaton -h task is executed.