Coaching Session 003

After a lot of trial and error and playing a bit with gulp I wanted to show you the gulp tasks that I’ve prepared to set up my development environment. There are still left the tasks that will deploy the production version of the web application, everything related to images and icons and a lot of stuff that it’s yet to come. But, anyway, to reduce the length of the posts let me introduce you the final gulp magic I’ll be using to start developing my project.


Quite self explanatory. Almost all of the are node packages (some are not yet used on the tasks).

Folder and file variables are stored in a config file:


General functions to provide reusable ways to log messages on the console and to delete files:


Specific tasks for my project.

help – uses the taskListing module to return on screen all the available methods


Apart form being call as help I’ve made it the default task so it will be invoked if we just typo gulp in the console (as you can see in the picture above).

clean-styles – to remove the existing styles.css where all the combined sass and css files will be. We remove it just before we compile the new one. This is a task that will be used rarely on its own but in combination with the sass compilation.

styles – it will call clean-styles just before compiling the sass files. It gets array of style files (normalize.css, main.css and *.scss) as its source stream, the compiles it with sass (normal css gets through without changes), concatenates everything as a single files called styles.css, then applies the vendor auto prefixing (thanks to postcss under the hood), saves it and sends a signal to browserSync to stream the new css into the browser and applies a pseudo-reload.

serve – it will call before executing anything else styles which will call before anything else clean-styles. After that we will initiate a browserSync instance (automatic reload on changes) pointing to the index.html on the src folder. We have two watchers: one for styles which will execute styles whenever a style file it’s modified (and it will get injected to the browser) and another one for directly reloading the browser with the new html and js files whenever they change.


This is the task I’ll launch when I start working and will remain active on the console waiting for changes.



The final folder structure is the one that can be found on the github repo. The idea is to have a final css and js files where everything is concatenated and minimised maintaining the priorities, especially on the style sheets, so we need the less possible http connections to get al the needed files to render the page. Later on I’ll be adding a target folder for the production version so new tasks will be added to automate all the workflow.

Next step is to analyse the code in the htm5 boilerplate and get only the required lines of code and files so we can start customising the to-do app.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *