Some ideas for future development about atom-grunt-runner

[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.