11–20 of 51 posts
This article should be titled "Maybe you should stop using Grunt for things it was never meant to do to begin with"
...I would like the task system to provide an abstraction for pipelining tasks. (Perhaps gulp helps with this?) Hmmm, perhaps someone needs to look at any gulpfile ever written, anywhere. gulp.src('src') .pipe(this()) .pipe(that()); Maybe it's frustrating for anyone who spent "18 months" hacking grunt, but gulp really is better. Both tools are built on node for Pete's sake; async really shouldn't be that hard.
I switched to skimming the article at: [If] you just want to set up your single project with a task workflow, then go ahead and use Grunt (or gulp). They will serve you just fine.
I probably just don't have enough experience. I like the idea that Grunt and Gulp are written in JS so using JS to build JS seems like a win. But...., aren't build systems supposed to do dependency checking and just built the minimal amount of stuff? Maybe few JS projects are big enough for it to matter or maybe I missed where the dependencies are checked but AFAICT the default is to build everything always.
I'm a bit confused, what are they using grunt for? We're using gulp, but it's basically the same software. It just compiles our coffeescript, tags some assets and moves some files around, perhaps run a minifier somewhere. In what situation do you need your build toolchain to do more than that?
I think I found myself in a similar situation as the OP. We have multiple different, but architecturally similar, products which each get their own Gruntfile. If we stop here, we're solid, perfect. Unfortunately, each product has multiple flavors which each need to build into their own separate output directories. For us, that's where the Grunt patterns break down and get awkward. It's actually been good enough for a…
I'm not convinced the shell scripts are a good alternative, though. (Maybe they are for your scenario.) I would like to write a follow-up post talking about this.
I probably just don't have enough experience. I like the idea that Grunt and Gulp are written in JS so using JS to build JS seems like a win. But...., aren't build systems supposed to do dependency checking and just built the minimal amount of stuff? Maybe few JS projects are big enough for it to matter or maybe I missed where the dependencies are checked but AFAICT the default is to build everything always.
First the build tool needs to load the build files that declare the dependencies, so it knows which dependencies to check. For big, distributed projects, this step can be slow.
I probably just don't have enough experience. I like the idea that Grunt and Gulp are written in JS so using JS to build JS seems like a win. But...., aren't build systems supposed to do dependency checking and just built the minimal amount of stuff? Maybe few JS projects are big enough for it to matter or maybe I missed where the dependencies are checked but AFAICT the default is to build everything always.
There are many, many build tools in JS-land. Grunt and Gulp happen to be the most popular. (This isn't really due to technical merit. They're popular mostly because they're popular.) My personal favorite is Jake, which is a classic Rake-like (or Make-like) tool.
...I would like the task system to provide an abstraction for pipelining tasks. (Perhaps gulp helps with this?) Hmmm, perhaps someone needs to look at any gulpfile ever written, anywhere. gulp.src('src') .pipe(this()) .pipe(that()); Maybe it's frustrating for anyone who spent "18 months" hacking grunt, but gulp really is better. Both tools are built on node for Pete's sake; async really shouldn't be that hard.
scripts: {
"do_something": "this | that"
}
$ npm run do_something
Shell scripts, when you're not dealing with autotools generated script, aren't really that big, or even that complicated.
Not to mention that the ability to chain disparate tools and subshells can be incredibly elegant and powerful.
I think JavaScript people might need to read it.