Some way to know when webpack end with watch option enabled?

I need to know when my webpack task ends and it start to watch the files change, i tried by this way, without success.

gulp.task("pack", function() {
  var stream = webpack({
    output : {
      filename : "bundle.js"
    },
    watch  : true
  });

  stream.on("end", function() {
    console.log("build end!");
  });

  return gulp.src("public/src/app/app.js").pipe(stream)
    .pipe( gulp.dest("public/dist"));
});

When i run the task with gulp pack command, webpack start to watch but never emits the “end” event, instead of that, when i remove the watch option or set it to false, the “end” event is triggered as well.

There is some way to know when webpack start listen for changes, using watch = true?

[wphampton]

For my use I finally got this working relying on the native webpack watch (specified in the webpack config) and not using gulp.watch() calls to monitor my .js source files. The key for me was calling the gulp “task completed callback” cb() on only the first task iteration (tracked with taskNum variable) within the stats/done webpack callback.

Also below are pieces to load in the external webpack config, adding webpack watch mode if NODE_ENV = development. Also webpackStatsConfig can be changed to get different output options. Also a version that does not use webpack-stream that helped me get to a little better understanding of what was happening…though I’m not sure which is “better”. Big thanks to @shama for his work on this front.

var gulp = require('gulp');
var webpack = require('webpack');
var webpackStream = require('webpack-stream');
var gutil = require('gulp-util');

gulp.task('webpack', function(cb) {
    var configFile = 'path/to/webpack/config.js';
    var configFileContent = require(configFile);
    var addConfig = {
        watch: process.env.NODE_ENV === 'development' ? true : false
    };
    var finalConfig = Object.assign({}, configFileContent, addConfig);
    var webpackStatsConfig = {
        colors: true, hash: false, version: false, timings: false, assets: true, chunks: false,
        chunkModules: false, modules: false, children: false, cached: false, reasons: false,
        source: false, errorDetails: false, chunkOrigins: false
        //context: '', modulesSort: '', chunksSort: '', assetsSort: ''
    };
    var taskNum = 1; // A counter to track how many times the webpack task runs

    // The block below uses webpack-stream
    return gulp.src('path/to/entry/index.js')
        .pipe(webpackStream(finalConfig, webpack, function(err, stats) {
            var title = 'webpack' + ' compile #' + taskNum + ':\r\n';

            gutil.log(title, stats.toString(webpackStatsConfig));

            // Only execute this callback the first time
            if (taskNum === 1) {
                cb();
            }

            taskNum++; // Increment the task counter
        }))
        .pipe(gulp.dest('path/to/dest/directory'));
    // End webpack-stream version

    // The block below does not require webpack-stream (not sure about pros or cons)
    /*webpack(finalConfig, function(err, stats) {
        var title = 'webpack' + ' compile #' + taskNum + ':\r\n';

        if(err) throw new gutil.PluginError("webpack", err);
        gutil.log(title, stats.toString(webpackStatsConfig));
        gutil.log('webpack is watching for changes...');

        // Only execute this callback the first time
        if (taskNum === 1) {
            cb();
        }

        taskNum++; // Increment the task counter
    });*/
    // End native webpack version
});

[shama]

As long as webpack runs in the same process, running it subsequent times will do incremental builds. So I assumed the watch option was for use without another watching library.

You might trying passing an optional callback to webpack(config, null, callback) to know when it has compiled. It doesn’t end the stream on purpose with watch: true specified. That behavior was added in this PR https://github.com/shama/webpack-stream/pull/4, it looks purposeful but I can’t say why as I’m not a consumer of that use case.