8

I have a gulp task called build that uses sub-tasks to move various parts of my source to a build folder:

gulp.task('build', ['jshint', 'templates', 'app', 'components', 'stylesheets', 'assets', 'index']);

gulp.task('app', ['clean-app'], function(){
    return gulp.src(config.inputs.app)
        .pipe(gulp.dest(config.outputs.root));
});

I then wanted to add some extra steps when --env=prod, which I did with gulp-if:

gulp.task('app', ['clean-app'], function(){
    return gulp.src(config.inputs.app)
        **.pipe(gulpif(env === 'prod', uglify()))**
        .pipe(gulp.dest(config.outputs.root));
});

This works fine. The final thing I want to do is to gulp-concat all the js files from those sub-tasks. I figure that I can use gulpif to return a stream from each task instead of going to gulp.dest, but I would still need to somehow conditionally run a task to combine those streams and concat.

Is there a better way to do this?

2 Answers 2

14

Rather than shove everything into one build task, why not have a separate task for compile or build-prod. This would make your code much easier to maintain, and less fragile.

You can still reuse parts of tasks, either by encapsulating those in functions:

function jsBaseTasks() {
    return gulp.src(config.inputs.app);
}

gulp.task('build', function() { jsBaseTasks().pipe(...); // etc }

Or, if you have chunks of reusable code, you can use lazypipe to build those up and use them as needed:

var jsProcess = lazypipe()
                    .pipe(jshint, jshintOptions)
                    .pipe(/* other gulp plugin */);

gulp.task('build', function() { gulp.src(...).pipe(jsProcess()).pipe(gulp.dest()); }

Also, I think it's a bad idea to have your production and development builds build to the same location. You are going to accidentally deploy the dev build at some point.

I have a rather big gulpfile that does this, if that helps to see what I mean, but it sounds like you've got a lot of work in yours already.

Sign up to request clarification or add additional context in comments.

1 Comment

Yeah you're probably right about the fragility actually - if I had a lot of environments I'd end up with if statements everywhere, hmm. Those are some good options that I'll try to make work for me. p.s I'm not building to the same location, my config file is generated from the env variable: config = require('./build.config.gulp')(env)
0

Definitely look to split up your tasks into as many smaller modules as you can really and then adhere to the DRY principle where you can.

In your case. For example, you may just have a standard dev task that gets you up and running and maybe runs some watch tasks and generic build tasks whilst you develop. When you want to deploy your code for a release, you may have some kind of options config that defines which files you want to push for release. Along with this you'll have maybe a release task that looks over the config file and then gathers all the sources you need, processes, concats, uglifies, etc. and then outputs to a specified build destination.

side note: It's much easier to now adhere to the DRY principle with the newest version of gulp-watch as you can now pass arrays as the callback function.

I have some gulpfiles which I'd be more than happy to share with you if you need a hand.

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.