Reputation: 3268
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?
Upvotes: 8
Views: 7675
Reputation: 1377
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.
Upvotes: 0
Reputation: 39580
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.
Upvotes: 14