Some ideas for future development

[tvooo]

Hey @nickclaw ,
I am the maintainer for sublime-grunt, the Grunt task runner for Sublime Text. I got my Atom invite today and am happy to see that you tackled the task of building a Grunt task runner for it, already :)

I would help you with a few pull requests, but I never used CoffeeScript, so maybe I can give you a few ideas on where to bring this plugin, instead.

Listing all tasks + multitasks

I understand that the fact that you're not listing all tasks is a bug. The way we extract tasks in sublime-grunt is more or less like that (removed a few unrelated lines, and it's JS obviously):

var tasks = grunt.task._tasks;
_.each( tasks, function( value, key, list ) {
  // Filter away reservered words that are none-targets
  var targets = _.difference(Object.keys(grunt.config.getRaw( key ) || {}), ['files', 'options', 'globals']);
  if ( targets.length > 0 ) {
    list[ key ].targets = targets;
    if ( targets.length > 1 ) {
      _.each( targets, function(target) {
        var name = key + ":" + target;
        list[name] = { name: name, info: 'Targets ' + name + '. ' + list[key].info || '', meta: { info: list[key].meta&&list[key].meta.info} };
      });
    }
  }
});

This should give you a list w/ all tasks + subtasks á la "compass:dev" and "compass:build", which you could then show in the task list. The fuzzy search of Sublime, and here Atom, helps a lot and the fact that you list all possible targets isn't a big deal because of this. We felt it was the best solution from a UX perspective.

Caching

I don't know if caching is necessary here. In sublime-grunt, we run a grunt command, pipe the output to Python and from there display the list of available tasks. The bottleneck may be somewhere there, but with huge Gruntfiles, we had to wait up to 2-3 seconds sometimes. We implemented a caching mechanism and this helped a lot. Might be interesting for atom-grunt-runner as well.

---

Cool, looking forward to see a nicely integrated Grunt solution for my next editor (maybe). You have the advantage of running an environment that is native to Grunt (JS/CoffeeScript), and you don't need to target different Python versions and platforms (as of now). If I can be of any help, let me know, I'll be glad!

Best, Tim

[nickclaw]

Hi @tvooo,

Thanks a lot for the great feedback! I'm currently in the middle of finals week, so I won't be adding anything for the next couple days, but your method of finding all tasks and subtasks is exactly what I was looking for!

Could you explain how your Sublime extension used cacheing? Were you originally running Grunt every time a user wanted to see the list of available tasks? Currently my extension parses the Gruntfile file once on startup in a totally separate process, which helps keep the extension load time in the 10s of milliseconds. The process returns a list of tasks after it has been completed, which is saved and used whenever a user pulls up the task list.

The one downside of that is that currently any tasks added to the Gruntfile aren't found until the Atom window is reloaded. The solution for that is probably to watch the file for changes, and get the tasks after each change.

Thanks, Nick

[tvooo]

Hi Nick,

yeah, the problem with ST is that it runs on Python. Parsing the Gruntfile wasn't an option. So instead, we "inject" a task called expose into grunt. In the beginning, we would spawn the grunt process with injected expose task from Python, which would output the task list as JSON that we could read from stdout.
Ergo: yes, we ran this task everytime the user wanted to see the list of tasks.

By now, the expose task creates a cache file with the JSON-encoded task list. This cache file also includes a hash of the Gruntfile. That way, we only have to read the cache file, compare the hash to the one of the Gruntfile and show the tasks. Much quicker. Of course, if the hashes don't match (i.e. the Gruntfile was changed) we run the expose task before.

You could work with the same technique, an md5 hash should be fine. Just save it internally, and check if the hash changed everytime you display tasks. Should still be really quick, and the list of tasks would be up to date any time.

Good luck with your finals!

[nickclaw]

That makes sense, I think I'll try to see if I can somehow watch the file for changes. Either through an Atom API like TextBuffers' events, or through a node module. That way I can preemptively parse the Gruntfile when it changes, instead of only realizing that it's changed when I need the tasks.

That should mean a little better UX, at the expense of an extra process running the whole time.

[tvooo]

Maybe you can hook a function into the Atom API that gets called when files change. I can imagine that they have a mechanism for that. This way, you wouldn't have to poll all the time and the footprint would be minimal.