...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());
How are all of you using any npm-based system combined with a continuous integration or clean build environment? It seems that a simple yeoman/grunt setup that just preprocesses some HTML and JS takes... a very long time. A minute or two just for the actual work. Plus 5-15 minutes for npm to make a thousand requests and write 10K+ files to the filesystem.
I hack around it by keeping node_modules around as a special resource on a custom build server and symlinking it in, but that wouldn't work with a proper "start from zero" build system.
Maybe I am missing something, but it seems like most of theses tools are working around the fact the windows doesn't come with make by default.
They are essentially reinventing the wheel for web developers who have never worked from the command line before.
This article should be titled "Maybe you should stop using Grunt for things it was never meant to do to begin with"
I started with grunt, then moved to gulp because I like the plugin support more and it felt less magical to me.
Then, I found that working with many different projects, gulp wasn't DRY enough for me. I kept copying any pasting my tasks across projects and forgetting to go back and improve them as I went. I also disliked the chain of require statements and devDependencies in my package.json. I was spending too much time coding my build.
So, I started a project [1] to move gulp tasks into re-usable functions and hide the devDependencies. Now I'm pretty happy with the result, my gulpfile [2] is now mostly configuration and very little code.
[1] https://github.com/lookfirst/gulp-helpers/
[2] https://github.com/lookfirst/systemjs-seed/blob/master/gulpf...
Check out Laravel Elixer[0]. It's built on top of gulp and exposes a very simple SDK for compiling the various parts of your app.
I feel I must be missing something here, but ...
The inability to specify config asynchronously turned into a disaster. Our primary need for async config was specifying temp directories for tasks to operate in. We used tmp, which does not have a synchronous api ...... I would like the task system to provide an abstraction for pipelining tasks
Is this abstraction not normally just called a program? Where you can do something like:
val tmp = makeTempDir()
generateFoo(outputDir = tmp)
generateBar(inputDir = tmp)
etc?
How much of this complexity is fundamental and how much is people attempting to work around Node's inherent limitations and fully asynchronous APIs? Perhaps the author should check out something like Gradle instead?
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 have had similar problems with my team, and I went with the "meta-project" approach. I created an external project with all default configs[1]. It works well-ish. Main complaint is speed, grunt really is dumb to not lazy load...
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 couldn't refrain myself for posting something I just wrote http://pothibo.com/2015/3/churn
I think JavaScript people might need to read it.
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 switched to webpack (the config is like ~100 loc) and it has replaced the need for a grunt or gulp file entirely.
grunt < gulp < webpack < make
I keep seeing people mention "a mess of shell scripts", and then use replacements which are dozens if not hundreds of lines of custom-configuration files.
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.