Why would you want to include grunt or gulp? Shell scripts do the job just as well and can be run from npm. Bash is streaming, parallel etc etc. You can do everything you want with &, &&, |, and >
Language preferences/fluency aside, I feel that there's much to gain from the JS "hash-based" way of expressing objects which are used as configuration objects (which can be dynamic) in task runners. I'm not aware of an easy alternative to this in shell scripting, but this is probably due to my ignorance on the subject).
* Saves me time so I don't need to figure out why a Gulp/Grunt script is behaving erratically, such as a watch that crashes even though exceptions are being caught for it
* Reduces my development depenencies, which helps with the following two things:
* There's less of a chance that there will be a package that needs to be built that will crash and burn on Windows
* I don't need to download a shit ton of stuff from NPM every time I clone from Git
* Helps me think about my architecture critically as I don't want to do anything too complicated outside of Gulp/Grunt
* I don't need to wait for someone to make a plugin for a test runner
I'm certain it's all possible, and while grunt and gulp have lots of examples I never really like them.
http://blog.keithcirkel.co.uk/why-we-should-stop-using-grunt... http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool...
It's less detailed, but also shorter and easier to digest.
Do I want to deal with writing the code / instructions to:
* Explain how to setup/install the build tools. * Account for differences in shell env. * Explain to windows users to get cygwin/whatever, or make a separate set of scripts for them.
No.
Grunt/Gulp have the benefit of having a consistent cross OS package manager (npm), in a language that the coder is likely to be familiar with should they need to tweak it.