Task CLI

[jugglinmike]

It's great to see a Grunt maintainer taking such a proactive role in promoting open standards; this demonstrates real commitment to the open source ecosystem.

To that end, @tjener and I were wondering about standardizing the command-line interface for Node Tasks. While it will be great when Node Tasks can be written independent of Node.js task runners, we would love to see a standard that includes command line invocation. This would make the Node Task ecosystem accessible to a much wider audience--developers could use individual Node Tasks without moving their entire build process to Node.js. For instance, they could use the uglify task by invoking its binary in their project Makefile:

dist/app.min.js:
    find lib/ src/ -name *.js | xargs uglify > dist/app.min.js

@tjener can probably speak more to the requirements than I, but I think the most basic requirement would be standardization around argument parsing, including flags (possibly with semantics around --version and --help).

Is this something that is on the project roadmap?

[tJener]

Ability to use command-line tools without needing to wrap them; maybe some kind of implicit wrapper spec for shell commands. I don't know if this falls under the purview of the task runners. An example in pseudo-grunt:

initConfig({
  cat: {
    shell: true,
    options: {
      args: [
        '<@= src @>',
        '> <$= dest $>'
      ]
    },
    files: [
      { src: [ 'src/**/*.js' ], dest: 'foo.js' }
    ]
  }
});

Then as @jugglinmike mentioned, going back the other way:

dist/app.min.js: dist/app.js
        node-task-cli-thing uglify $(UGLIFYOPTS) $^ > $@

[tkellen]

Hey you two, thanks for joining the conversation! I'm simultaneously stoked that you're excited about the project and bummed by how little time and focus I've been able to give to it thus far.

When it comes to standardizing option parsing/help, I think we have that handled. From the spec:

options ≈

If a task allows options, they must be enumerated under this property as an object where the key is the option name and the value is an object which contains, at a minimum, key/value pairs for description and default. This property is primarily intended for task runner introspection, but authors are encouraged to use it for applying default values in parseConfig.

So, I'm not sure it makes sense for CLI stuff to be defined in the spec? At first blush it seems like this integration could be solved with a barebones task runner that mediates between the task instances and whatever is trying to work with them. What specifically are you thinking would need to be added to support your use case?

[jugglinmike]

Mostly, I'm trying to anticipate the workflow around using these tasks directly. My thought was that, in defining standards, we would consider the CLI for tasks in the same way we consider their JavaScript API. At a high level, my motivation is to define tasks in such as way as they are generally available for tool chains that don't otherwise use Node.js.

An example of how a bare-bones task runner would be invoked as an interface between Node tasks and Unix utilities would help me understand your suggestion. Would you mind making one up?

[tkellen]

I just finished building all the requisite utilities to make writing a bare-bones cli runner possible. Please check out the wiki if you're curious to see how things are shaping up.

Ben and I are going to do some review tomorrow. As soon as we have things ironed out enough to build the first bare-bones runner, I'll get you a sample.

[jugglinmike]

Thanks for the update; keep us posted!

[tkellen]

Closing this now--it's out of the scope for what we're trying to do here, but a really great idea!