what is a task?

[millermedeiros]

I think it needs a clear definition of what consists a task. Is it just a helper module? What is the goal of a task? Why do we even need a task spec? etc...

I think many of the doubts and mixed opinions comes from different perceptions of what consists a "task" and also because of different needs. Maybe that will help to clarify a lot of stuff.

[tkellen]

To my mind, there are roughly four basic needs that should be universally supported by all task runners.

• An arbitrary unit of work accepting some configuration that can be invoked by the runner of your choice (basic spec, example: running a test suite)
• Iterating input and neither reading or writing it directly (no spec (yet), example: running a test suite)
• Reading and processing input but not writing anything (reader spec, example: linting)
• Reading/processing/writing data (writer spec, example: everything build-process related)

The biggest win lies in the writer extension of the spec, which defines a common method that can be used to pipe source input and destination output through an arbitrary pipeline of tasks.

Finally, a task should be able to complete its work without a runner (ie: invoked manually).

[millermedeiros]

Gradle & Other Environments

Gradle Tasks can sometimes work similar to a static method (just execute some code inside of it) and sometimes the task can actually inherit from other tasks, a good example is a custom task that inherits from the Copy Task. The reason why they inherit from another task is because they want to use a DSL for that kind of operation and it wouldn't be as easy to implement it by simply passing config hashes around to methods (and they probably need to map it to Java classes), I think JavaScript/node it's a totally different situation but there are still some things that could be borrowed or used as an example of what not to do...

---

Disclaimer

I'm not using grunt or automaton and most of my build scripts are just a series of static functions that receives and input and produces an output (example) and most of the node.js libs I've been using are just some simple functions that accepts a few config options (usually an object) and produces an output, that's probably why for me it's kinda hard to understand some of the design decisions and even the need of a task runner and/or common spec.

The reason why I'm asking this kind of questions and giving some opinions once in a while is because I want to make you guys think more about what problems you are trying to solve and if there is a different solution. Don't take everything I say as a good idea because it probably won't be - I didn't even spent too much time reading all issues (been a very busy year so far) and probably have different needs/opinions.

[tkellen]

I think the root of the problem is that you're too focused on your own needs when considering the utility of a task runner. Think of it this way: Grunt makes it possible for someone with basically no programming skills to set up a modern build process in like 20 minutes. Would a designer be able to maintain your build files?

[tkellen]

RE: the copy example, grunt doesn't need that sort of thing, it has this (which will be supported in an external lib soon): http://gruntjs.com/configuring-tasks#building-the-files-object-dynamically

[millermedeiros]

@tkellen exactly, a designer would never be able to write a build script like the one on mout. Most people wouldn't even know where to start and even if they did would probably become a huge mess pretty soon and end up wasting more time. I'm against the whole grunt plugin hype because many plugins are basically duplicating the same work as a standalone lib (eg. the RequireJS plugin which is almost the same as running requirejs.optimize() manually) or implement features that could be extremely useful outside the build script context. The spec should make it clear why it was created and which problems it solves.

about the Gradle Copy task you are right - the grunt config already works as a FileList DSL - that's why I said that JavaScript is a totally different situation, we could use plain objects or chaining or require external modules/methods whenever we want. It was more to show that Gradle built the whole system thinking about OOP and inheritance (because it is mostly for Java projects) maybe there are good things to borrow, and maybe we should look at it through the JavaScript eyes adapting it to our context - maybe the whole Task being a constructor is the wrong approach since most node.js modules are static and receive a callback... (I'm not saying it's wrong, just that we should have a good reason to do so). It won't be easy to convince a lot of devs to jump into another boat.

[tkellen]

I'm for the whole "grunt plugin hype" because it presents a semi-unified interface that anyone can use to accomplish like 500 different things. The beauty of Grunt is that you don't need to know the implementation details of every library you're trying to use, you just define some files and some options and you're off to the races.

The goal of the spec is to make this declarative abstraction even more powerful. If we do it well enough, major library writers might even support their own node-task implementations, which is, to my mind, the holy grail of this little adventure we're on. It'd be great if we accomplish it, but if not, the community has already shown there is a strong desire for a unified interface to all of the drudgework that is building a modern website/webapp/javascript thing.

It's clear you're against that abstraction. I am not.

[sindresorhus]

The semi-unified interface is one of the best selling-points of grunt.