Dynamic environments for your gulp tasks
At Wolox we are gulp lovers! After giving it a try on some projects we had no doubts and adapted all of our frontend build and deploy pipelines to that awesome tool.
However, when working on big projects that have different user environments (qa, stage, production, etc), you’ll probably find yourself rewriting some of your gulp tasks for each new environment that your team needs.
This post will show you common approaches to deal with user environment configurations and how we found a scalable solution.
Let’s take a look at a simpler version of the task that compiles our javascript during development. Basically, we check our code styling. We use eslint, then transpile the es6 code using babel and applying sourcemaps.
Pretty simple, right? Then, to deploy that code in production, we need to minify and concat those js files. Neither linters nor sourcemaps are needed.
The first simple approach is to create different tasks for production that cover our needs.
Taking a quick look at this approach, we need to create many new tasks to build our project for production environment: js:production, css:production, vendor:production and build:production. The downsides are obvious, we need new tasks for each new environment that has different settings, repeating the steps each time and, of course, all those tasks need to be maintained!
Let’s make a smarter approach.
We can create a config file that let us know which environment is currently being used.
Then, these will be our js and build tasks.
This approach is by far better than the first one. We could abstract the presence of two different environments in the same task and only needed two new tasks that are really simple: build:production and set-production. Even more, there are a few tools that will help you to make it even simpler: check gulp-environments or gulp-util.
But, what needs to be done for new environments? Pretty simple, two new tasks for each one. But what if those environments have different rules on minification, concatenation or even add different processing? Let’s suppose our qa environment wants to concat the source files but keeping them unminified.
See also: Building Apps with Parse BaaS
As new environments with different rules are needed, our gulp tasks start getting too wired, with long and even complex conditions on each action.
So what if I tell you that we can avoid these tangled conditions, and also avoid the need of creating tasks for each environment?
Dear reader, I introduce you to our final solution:
What does this code do?
We use yargs to read the command line params of the task being used, and then search for a configuration file named after the env param.
What does that file look like? Here are examples for development and production.
The configuration approach changed completely! We used to decide what action to do according to the environment, but now, each environment chooses its own actions.
Let’s check the js and build tasks.
Did you see what happened? We didn’t need new tasks, we didn’t need long rules. The only thing that is needed is a configuration file, so flexible that you can set up your environment to do whatever you want and even create new rules, and so scalable that you can have the number of environments you want.
So, whenever you want you gulp tasks to be executed for a special environment, just specify it with the env param.
Gulp is an awesome tool, hope this post helps you make it even better!
For extra help on deploying your apps with gulp, check one of our latest posts on it! You can also checkout our starter kit on github!
Posted by Sebastián Balay (sebastian.balay@wolox.com.ar)
