Interesting approach! On the one hand, I love the expressiveness and human-readability of the task runner definition. On the other hand, I'm slightly irked by overloading markdown syntax with different meaning: first-level header is task name, so what is second-level header?
Thanks for the comment!
I admit it's a little unnatural to interpret markdown in this way. Probably this approach only works for very simple use cases.
But IMV task definition is simple enough thing which fit into the subset of markdown semantics. So I choose it for config language.
BTW all levels of headings have the same effect as the first-level!
Doesn't make senses that a second-level inside a first one do the same think that the first-level do and something more?
saku doesn't do anything special for the levels of headings, but the user can use the different levels of headings for expressing, for example, different significances of tasks.
saku build:js build:css
browserify blah blah
sass blah blah
Where build is at the 1st level because it's an important task, and build:js and build:css are at the 2nd level because they are less important.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.