Front-End Insights

WebPack and Gulp together


Last time I wrote about WebPack as an alternative to Gulp. The conclusion was that, in smaller projects, it might be sufficient to only use WebPack. But if its capabilities are not enough for our needs, we can use both WebPack and Gulp together. Today I will shortly describe how to configure them combined.

Sample configuration

As I have already written about these two tools, you can check previous posts about them before further reading:

Now, if you know how to deal with Gulp and WebPack, let’s see the sample Gulp configuration which runs WebPack as a task:

    gulp = require('gulp'),
    gutil = require('gulp-util'),
    webpack = require('webpack');
gulp.task('webpack', function(done) {
    // run webpack
        entry: './app/app.js',
        output: {
            filename: './dist/js/app.min.js'
        module: {
            loaders: [
                { test: /.js?$/, loader: 'babel', exclude: /node_modules|bower_components/, query: { presets: [ 'es2015' ] } },
    }, function(error) {
        var pluginError;

        if (error) {
            pluginError = new gulpUtil.PluginError('webpack', error);

            if (done) {
            } else {
                gulpUtil.log('[webpack]', pluginError);


        if (done) {

gulp.task('default', ['webpack'])

Ok, at the very beginning we require three node modules (which can be installed via npm command). Two of them are obvious, but the third (gulp-util) will be needed because we want to track WebPack errors and pass them to Gulp while running the task.

Next we have a definition of the task which is, suprisingly, called webpack 😉 In its callback, we just invoke the webpack function passing a configuration object to it. I will leave this object without comment because you should already know what is going on here from my previous post…

What is interesting here is that the webpack function receives the second parameter – a callback function which is fired after WebPack processing is finished. In this function we can just intercept the error from WebPack and get Gulp to handle it (once again – this is why we are using gulp-util), so the user can see the message while running the task.


And actually this is it 😉 Of course in a real project this configuration will be much more complicated. Recently at work I spent a couple of hours configuring WebPack and Gulp, AngularJS, Babel, ESLint and some other cool stuff… However, knowing how to deal with WebPack and Gulp together might be a good foundation for building a sophisticated development stack.