@jmeas I'm using run-sequence, but if the webpack task set watch to true, the task after webpack will never be executed.

For example:

gulp.task('webpack', function() {
  return gulp.src('...')
    .pipe(webpack({watch: true}))
    .pipe(gulp.dest('...'));
});

gulp.task('otherTask', function() {
  return gulp.src('...');
  // ...
});

gulp.task('build', function(cb) {
  runSequence('webpack', 'otherTask', cb);
});

Then run gulp build, the wepback task will be executed, but otherTask will not.

from webpack-stream.

@minwe / @Hurtak, I had the same issue. I got around it with some clever finagling.

/* as part of the JS build task... */

// keep track of our first build
var firstBuild = false;

// ...start the stream, and then...
    .pipe(webpackStream({
      watch: true,
      // ...the rest of your config 
    }, null, function() {
      if (firstBuild) {
        $.livereload.listen({port: 35729, host: 'localhost', start: true});
        watch();
      } else {
        $.livereload.reload('http://localhost:5000');
      }
      firstBuild = false;
    }))

Define your watch fn like so:

function watch() {
  // for example...
  gulp.watch('src/stylus/*.styl', ['stylus']);
  $.livereload.listen();
}

Now running the task that builds your JS will also set up a watcher for your other things. Just be sure to run that task in the last "grouping" within runSequence. For instance, you could do...

gulp.task('work', function(done) {
  runSequence(
    ['lint', 'clean'],
    ['images', 'fonts', 'copyAssets', 'stylus', 'build-javascript'],
    done
  );
});

where build-javascript is the one that runs webpack with the watcher.

Lmk if you have any problems with this method!

from webpack-stream.

@jmeas I created a PR that should address this in a more gulp friendly way. See #109.

@minwe @Hurtak This should also resolve the issue with run-sequence—as well as Gulp 4's series and parallel.

Let me know how this works for you.

from webpack-stream.

@minwe, correct. From my description above:

Just be sure to run that (webpack-stream) task in the last "grouping" within runSequence.

The current behavior produces a never-ending and blocking stream. With hope, @minwe's solution, #109, will be a proper solution rather than the "clever finagling" that I went with. I've been meaning to pull down the branch to try it out for myself, but I haven't had the free time.

from webpack-stream.

Update: the error is the conditional around this line. Removing that solves the problemo.

Will update with more as I find it...

This was added here, 094e933, without any explanation.

@shama, do you know why "Elie Rotenberg" added this? 😮

also ping @elierotenberg if you're the author of that commit 😛

from webpack-stream.

Well, even with the bug resolved this doesn't help my original problem. 😦 While the initial build works awesomely, subsequent updates to a file don't trigger the concat task to run!

The search continues...

from webpack-stream.

@jmeas That is a weird bug. Although it sounds like you can handle this use case purely with webpack. Which is recommended as webpack will handle the incremental builds much more efficiently than trying to connect up with gulp.

Instead of multiple entry points, you can create a single entry point that loads each of the previous entry points.

Otherwise check out the CommonsChunkPlugin: https://github.com/webpack/docs/wiki/optimization#multi-page-app in which you can control which parts of common chunks across multiple entry points are shared into a single file.

As for requiring globs of files, you can do that with webpack require.context:

var requireTest = require.context('./test', true, /_test\.js$/)
requireTest.keys().forEach(requireTest)

Which will require any file in the ./test folder that ends with '_test.js'.

from webpack-stream.

Hi!
My commit merely changed the code organization for consistency, absolutely 0 semantics impact IIRC!

It seems that the conditional was added here instead: 4036e53

from webpack-stream.

@jmeas That is a weird bug. Although it sounds like you can handle this use case purely with webpack. Which is recommended as webpack will handle the incremental builds much more efficiently than trying to connect up with gulp.

Yeah, I'm beginning to think that may be the case.

Thanks for the options on different ways to do this. I discovered the LimitChunkCountPlugin, which seems to be another way to get n => 1 builds. I'll prob. take a look at these other options to see if any seem cleanest/simplest/etc.

My commit merely changed the code organization for consistency, absolutely 0 semantics impact IIRC!

Ah! Thanks for the clarification.

from webpack-stream.

👍

from webpack-stream.

I got this problem when using webpack-stream with run-sequence.

from webpack-stream.

same thing here, run-sequence does not continue to next task when watch is set to true

from webpack-stream.

@jmeas Thanks. I'll try it later.

from webpack-stream.