90% of the time I see one of these build systems in place, all they are doing is running browserify, then minifying the results. Maybe they have a stylus compilation or a couple things thrown in on top. Either way, most of these tasks would be much less complex in simple bash or node. Does a build script like this really need to be abstracted away?:
And yet there are still requests on this project to switch over to grunt or gulp. I just do not get it in most cases. Big tools when not required create a sort of open source equivalent to "vendor lock in".
That's exactly the case for what substack proposes. To me, these systems are a requirement in Windows. In other platforms, it's a matter of preference and convenience.
You might prefer to write your builds in Node because you write your app in Node as well. Your team might not know bash.
I think having options are healthy, as long as you pick the most reasonable one for your use case.
> You might prefer to write your builds in Node because you write your app in Node as well. Your team might not know bash.
This is a good point. In the example I linked to, I am actually planning on switching it over to node specifically for windows users. The reason I have not yet is that I handle all the builds so it has not really come up.
Not sure if Grunt or Gulp do this, but Make will only run compilation if there have been changes since the last time it ran. Not something you're going to get with writing your own shell script.
https://github.com/morganherlocker/turf/blob/master/build
And yet there are still requests on this project to switch over to grunt or gulp. I just do not get it in most cases. Big tools when not required create a sort of open source equivalent to "vendor lock in".