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 ended up writing my own build library (npm install crankshaft). Docs aren't up yet, but here's what build scripts look like - https://github.com/jeswin/hitchslap/blob/master/build.js (simple example) and https://github.com/jeswin/fora/blob/master/www-client/build-... (more complex, with dependent tasks)
They're not always portable. Some people develop on windows.
Considering that teams frequently homogenize on one type of machine - bet it windows or Mac or Linux, shell scripts are typically portable enough for these use cases.
Hmmm, perhaps someone needs to look at any gulpfile ever written, anywhere.
gulp.src('src')
.pipe(this())
.pipe(that());
scripts: {
"do_something": "this | that"
}
$ npm run do_something
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.
2) We use StriderCD, the self-hosted CD/CI, and it too supports caching node_modules. 2 minutes is a 'long' time for us from git push to autodeploy.
3) We use gulp and npm always. Grunt and bower are a mess.
EDIT: Also, we npm shinkwrap projects. It avoids numerous issues and makes module caching a natural part of the process.
grunt has its issues, but you are correct that bower is truly a mess. "Let's do one of the many jobs that npm (the tool we use to install bower) already does, but not as well!" No thanks.
I have not experienced this. I built a 15k+ line CoffeeScript app. Every time a file changed it would compile it to JS and run thousands of unit tests in ~1 second.
As for the clean NPM... I never deleted that directory. I believe I read an article somewhere that you should actually commit your module dir. Maybe that's no longer in vogue though?
They are essentially reinventing the wheel for web developers who have never worked from the command line before.
I rarely find them to be limitations for my projects, but there's certainly a reason so many different build systems have been built, even for Linux.
Yeah, I guess you can get make to do the exact same things as gulp, but gulp already does what a web developer needs, in a language they already know, with a massive plugin ecosystem you don't have to re-implement in shell.
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...
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?
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.
Your grunt or glup file can run a command to check for those dependency and update it via bower and npm.
Bower are for front end dependency check and NPM are for the backend dependency check.
Grunt and Glup are more of a task management system where you run tasks. Such as transpiling your jade/haml/sass, minifying your js, running your test cases. You can run these tasks in specific orders.
There's also gruntfile too but it's been a while since I've use these things. I think gruntfile are for grunt specific module for tasks though, so it'll dependency check grunt modules?
I'm a recovering frontend guy, well at least I did front end in a few gigs that were suppose to be fullstack.
In what situation do you need your build toolchain to do more than that?
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 think JavaScript people might need to read it.
[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.To be specific, what advantages does webpack have over gulp that webpack doesn't also have over make? (I would also accept advantages that gulp has over grunt that gulp doesn't also have over make.)