Gulp Build SystemPart 1: Fundamentals

What Is A Build System ? 

A build system is simply a collection of tasks (commonly called “task runners”) that automate repetitive work. Typical usage would include compiling preprocessed CSS and JavaScript, concatenation, minification, firing up a server for automatic browser reloading and creating a deployment build. Build systems usually work in tandem with other tools like package managers. While there are literally countless ways to configure your build system lets take a look at three of the most common components in a typical front-end workflow.


1. Package Managers

Package managers are tools that are used to automate the installation, upgrading, removal, and dependencies for the packages and libraries used in your dev environment. We will be using both Bower and NPM (Node Package Manager) in our upcoming workflow. If it seems redundant to use two package managers instead of just picking one or the other I completely appreciate where you are coming from. It took me quite a bit of research before I started to understand the subtle distinction between the two. While both manage dependencies, their intended target environments are different.


As you can see in the diagram above, Bower manages our front-end dependencies while NPM is used to manage dependencies within the Node.js environment. If this still seems a little confusing then look at it like this: Bower is used to manage libraries like jQuery, Backbone, or RequireJS that affect your actual project files. NPM on the other hand handles utility modules that work with node to assist in your build process.

2. Preprocessors

Preprocessors are critical to an efficient modern workflow by adding additional features and an optimized syntax that compiles into its native language. Some of the most popular preprocessors used for CSS, JavaScript and HTML include:

  • CSS: Sass, Less, Stylus
  • JavaScript: CoffeeScript, Typescript
  • HTML: HAML, Jade, Markdown, Slim

3. Task Based Build Tools

Now lets get to the meat of it, Gulp and Grunt. Both run on Node, both are great tools, and both share a similar anatomy. Although we will be using Gulp in this series, Grunt follows the same overall structure. We will be getting into a few of the core differences between Grunt and Gulp in the next section, but for now lets take a look at the structure of a typical gulp.


Starting at the top and moving down, the first step is to declare which modules will be required by Gulp. This is where we declare both gulp itself as well as all the dependencies we need for our build.

Following this we have our named tasks (name them whatever makes sense to you) which tell Gulp what you would like it to actually do. One optional task that is also frequently added is the ‘watch’ task. When you add this special task you specify certain files and folders that you want Gulp to watch. When Gulp detects a change, it will automatically run one of your named tasks.

// named task 'scripts'
gulp.task('scripts', function(){
 // code 
// watch folder 'js' for all files ending in .js.
// On change runs 'scripts' task
gulp.task('watch', function(){ 'app/js/**/*.js', ['scripts'] );