coaching_002_main

Coaching project 002

It’s been quite a gulp week to me. I have a lot to explain and very few time as tomorrow is my first review. I can say that in just a week I’ve learned a lot about something that was totally unknown before I started and, as always happens, once you know it you realize it was not that difficult. Mastering anything takes time but the difference from going from zero knowledge to some knowledge is huge. In fact I just skipped one of the next steps (modularizing gulp) to be able to write this post.

I assume you know or at least understand what gulp is about. If not, take a look at gulp site and come back, I’ll show you some really easy-to-follow code. If you are just a friend of mine without coding skills probably you’ll get bored if you keep reading, but thanks for the visit =)

Setting up

By far gulp was one of the things that I was most interested on. Being able to automate all the front end tasks sounded like magic but it’s not, it’s quite simple in fact. Let me explain:

First of all, we’ll need gulp itself which is a node package that we can install using npm (should be installed in your system along with node), first as a global package:

Then we go to our project root folder and initialize npm so we have our package.json where all the dependencies will be written down.

And now we can save our first package as a project dependency:

Our package.json will look something like this:

This file is created with npm and every time you install a node package the devDependencies will grow with the package itself and its version.

This could be the easiest next step, some sort of “hello world” for gulp, quite straight forward to understand:

gulp.js

Let’s grab my gulp file piece by piece. These are the packages I’ll be using for my project (I’ll probably add more in the future). All this packages will be installed/stored in the node_modules folder in the root of the project.

  • npm packages: exactly that
  • config file: with variables to paths and constants (stored in root too)
  • implicit plugins: gulp plugins (as normally required)
  • plugin loader: a plugin that loads plugins on demand so if we need gulp-sass we will call $.sass instead where “$.” equals “gulp-” as part of the package name

lint is a task that uses the very same .eslintrc file (Airbnb ES6 style guide) on our root to lint the code.

log is a function we created to present more colourful messages on terminal using the utils.color method.

This is the same as Atom is doing on real time thanks to the linter plugin and the linter and linter-eslint atom packages. This is the result of parsing a normal JS file with a ES6 linting stylesheet:

coaching_002_001

Gulp can surely get much more complicated but this far all my tasks look quite similar to this one. Some of them have a prerequisite (one or several tasks run before the invoked one) which can be achieved with this syntax:

We are executing the clean-styles tasks to delete the temporary folder with css files before we save the output of the sass complied files by the sass task.

You can find in the repo all the tasks of the gulp file including some with nodemon to start and restart the node server when modifying files of  a node application and the useful browserSync to reload the browser every time we modify or recompile the files we specify.

Some random thoughts about gulp

There are some packages that you can find as normal raw node packages or the gulp plugin version. I have played around with three different setups to do the same task:

  • npm raw packages
  • gulp plugins
  • lazy loaded gulp plugins

And as far as I can tell there’s not really a performance gain or loss in any of the three cases. I tried an scenario in which the workflow was: getting a css4 file as source and pipe to cssnext to convert it to css3 and then generate the css with vendor prefixes with autoprefixer. This is the file conveniently written to show some css4 syntax and a last rule which needs vendor prefixing:

Times in milliseconds:

  • With plugins: [413, 457, 376, 396, 400] Average: 408ms
  • With lazy plugins: [414, 400, 404, 398, 396] Average: 402ms
  • With postCSS: [473, 471, 447, 530, 456] Average: 475ms

This times are too big for a simple transformation like this stylesheet. My feeling is that most of the time is spent in opening the stream of files, piping actions and writing files than really processing the files. I’ll leave these three combinations to test further as the project grows so we can get some nice performance figures. My guess is that once the files grow or the piped processes increase postCSS will be the winner by far. We’ll see.

Final words about gulp (this far)

I am not a master but after about 10 hours battling against gulp I really think we finally understand each other and the love is growing stronger every day. So, please don’t tell me anything about webpack yet and let me enjoy the moment.

It’s nice to be able to do all kinds of stuff but after this gulp hardcore training I really think I can go to the next phase and just adapt my gulp necessities as the project grows.

Two last comments about my work till now:

Other stuff

Un comentario en “Coaching project 002”

Deja un comentario

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