gulp.watch() and the initial run

[mprobst]

It'd be nice to allow starting an initial run for a gulp watch, e.g.:

gulp.task('watch', function() {
  return gulp.watch(['src/**/*.js', 'test/**/*.js'], {initialRun: true}, ['test.unit']);
});

Currently the only way to achieve this is to manually trigger a gulp.start, which is undocumented and thus a bit ugly.

[lholznagel]

When I understand your problem correctly, maybe this would help you:

gulp.task('watch', ['task.before.watch'], function() {
  return gulp.watch(['src/**/*.js', 'test/**/*.js'], ['test.unit']);
});

With this code, all tasks in the square brackets will start before the watch task.
here is no need to use gulp.start

[mprobst]

Not really. My ['task.before.watch'] equivalent fails with an error normally, so in my watch task I first have to configure it to not fail the build:

gulp.task('watch', function() {
  failOnError = false;  // Don't process.exit() on errors.
  gulp.start(['test.unit']);  // Trigger initial build.
  return gulp.watch(['src/**/*.ts', 'test/**/*.ts', 'test_files/**'], ['test.unit']);
});

So if I have a task start before it, I'll never even make it to the watch operation.

[lholznagel]

Okay, why does it fail, I use a similar watch task and everything runs like a charm

[callumacrae]

I solved this by using a flag like --fail to control whether the build should fail on error, so I would run gulp test.unit --fail or gulp watch.

I don't think it would be a good idea to add this option, it is a very, very specific case. I think the solution would be even easier in Gulp 4 as you can just call the function, too.

[mprobst]

I think this is a super common use case.

• If your unit tests fail, the build should fail. This should be the default, otherwise you risk releasing/deploying/... software that's broken (and avoiding that was the whole point, after all...).
• The only real way to fail in gulp is emitting an error, which exists the process
• For gulp watch, you do not want to exit the process - again that's the whole point.

Sure, you can pass --myFunkyFlagThatChangesEverything on the command line to control behaviour, but then all users have to learn your funky flag, it'll be different between projects, and everybody has to figure this out by themselves.

This should be default behaviour, or easy to achieve, without any hacks. It's the whole point, after all ;-)

[phated]

3.x is feature locked and the file watcher is completely different in 4.0 where we just wrap chokidar. We don't want to add extra functionality on top of chokidar.