Which task runner should I use?

Task runners are very important in front end development, so important that we have plenty options.

They are all very good at what they do and they all work very differently from each other.

Their use cases are basically the same:

Build files (Preprocessors, concatenation, Minify, etc) Watch files for changes Serve our static files over a static HTTP server

And that is pretty much how the stack works. Watch -> Build -> Serve our pretty little code files.

They have one huge thing in common. They all rely on NPM and NodeJS.

Once you chose your favourite task runner you now start building up your scripts.

I wanna use SASS!

Great! SASS seems to be the most used CSS Preprocessor so it will fits perfectly on the example.

Let’s say you use Grunt and probably the grunt-contrib-sass package. In that case you’ll will need to have Ruby and sass gem installed on your system (Which is not something that NPM can handle). The pain in the ass in this is that you should not only have Ruby installed but also a gem (which it has its own versioning) called sass.

In case you use Gulp you are probably using gulp-sass which rely on node-sass and they both have their own versions to manage.

The question is:

Why don’t I use node-sass or sass gem directly? Why should I install a bunch of packages and setup a bunch of tools for this?

Which brings us to the following alternative.

Why don’t you use NPM as your task runner?

You’re already using it to manage your Grunt/Gulp/Etc, packages. Why don’t you use it for scripting as well?

Let’s use the example above. You are trying to use SASS as your CSS Preprocessor and you want a script to build your SASS file and generate a CSS.

Let’s use node-sass and post-css to handle our compilation, prefixing, etc.

Just npm install node-sass postcss-cli — save-dev to install them and save to your package.json file.

An important step here is to add ./node_modules/.bin to your path

We should now add our script to build them.

To build your sass you can now run npm run css:build. Simple as that.

In case you need to watch files and them run a script you can use a package called gacher that watchs your files and run a predefined script.

But what about bower. You said it doesn’t need bower!

Bower works greatly to handle all our front end dependencies. Except when we need to build third party library instead of using the minified version and when this happens:

We all went through this at least once.

But that’s ok. Most of the times we declare the dependency inside our bower.json anyway.

We can do this NPM style with Browserify. Browserify exposes our node_modules required packages so our browsers can use it as well.

For that scenario I’ll propose the following folder structure:

js/app/ (Which includes all your angular application)

js/libs.js (Which will includes all your library dependencies) scss/index.scss (Which is your main scss file meaning that this file will import other ones) img/ (Which will include all of your assets imagery) www/ (Which will include your distribution application)

www/css

www/js

www/img

www/index.html

Most front end modules now supports NPM usage with browserify as well.

Let’s say you wanna use jQuery. You just need to npm install jquery -s and them inside your libs.js you should include them.

window.$ = window.jQuery = require('jquery');

And them build with browserify.

You can see the full boilerplate here: https://github.com/grillorafael/angular-boilerplate

This boilerplate includes:

ESLINT JS Concatenation and minification SASS Autoprefixr Imagemin Angular templates Browsersync

Thanks guys!