Skip to content

Instantly share code, notes, and snippets.

@the-simian
Last active August 29, 2015 14:16
Show Gist options
  • Save the-simian/795ae3acc97ceeaf17bf to your computer and use it in GitHub Desktop.
Save the-simian/795ae3acc97ceeaf17bf to your computer and use it in GitHub Desktop.

#External Task Groups in Gulp.

###Goal: Create a group of reusable tasks as a fully seperate module, that can maintain their dependencies, and be integrated into many other projects. The reason to extenalize these, is for a few reasons. Firstly, I Imagine this as a private module for myself or my shop to use. In some ways it violates the modularity of existing npm modules. This isnt a single purpose item sporting the usual prefix gulp-whatever. Another reason is it allows to keep a standardized stask list for a shop up to date across multiple projects, without duplicating the code in many projects. In our case, we have some frontend devops tasks , such as complxity analysis, hintling, linting, test runnign and so on. We want to be able to maintain that process, while giving everyone a similar entry point. If we improve the 'shops devops tooling' it would be nice to not have to go to every single project and add more code. Finally, this allows the quite large list of gulp- dependencies in the npm file to be greatly slimmed down.

###Approach: I imagined the gulpfile: would still be extensible in the project. This way wecould bring in 'shop level' tasks, but still leave the capability to extend with project-level tasks if necessary. It would also be necessary to pass some configuration into the required task-group-module, in order to make it behave correctly for the project.

###Problems Currently, as is, gulp is a singleton, as far as I can see and simply requiring the external module isnt actually registering the tasks. It also doesnt allow me to pass recieving projects options into the required module. I'm doing something kind of like this in the recieving project's gulpfile.js:

Pardon the ridiculous naming, I'm jsut trying to be very clear to demonstrate what I am doing.

var gulp  = require('gulp');
var _ = require('lodash'); 
var options = require('./configuration-options-file');
var myGroupOfTasksModule = require('@myprivatenamespace/shoptasks')(options);

gulp.tasks = _.extend(gulp.tasks, myGroupOfTasksModule.tasks);

//then down here add any project-level tasking

Now what this means is that in the shoptasks module I am requiring, I have to basically write all the gulp tasks as if they were a normal npm module by using module.exports with a function.

like this in its index.js:

var sometask = require('gulp-whatever');

function ShopTasks(options){
  
  function anotherTask(){

    var importantConfigurationStuff = options.someValue;
    //whatever you do with gulp.
    
  }
  
  gulp.task('task-one', sometask);
  gulp.task('task-two', anotherTask);
  
  return gulp;
}

module.exports = ShopTasks;

###Solution In the external module, when it is require, pass in the options it expects to have, and in the external module return gulp. In the project, before registering the project's own tasks, extend the gulp singletons .tasks with those of the incoming module.

I'm mainly asking if this is way off base. I don't imagine a super monlithic project with everything we would ever use, necessarily, but out of convenience be able to group some of our common tasks. The point of me asking about this is to make sure i'm not following some outlandish antipattern for this, if theres a much more obvious solution to including another module that registers tasks. Otherwise this is working well, as far as I can tell.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment