Deprecating gulp.run no longer allows defining logic before running tasks.

Given a gulp file similar to the one below, before version 3.5 I was able to run some logic before running other tasks.

var shouldMinify = false;

gulp.task('js', function () {
    return gulp.src('./js/*.js')
        .pipe(concat('app.js'))
        .pipe(gulpif(shouldMinify, uglify()))
        .pipe(gulp.dest('js'));
});

gulp.task('develop', function () {
    shouldMinify = false;
    gulp.run('js');
});

gulp.task('build', function () {
    shouldMinify = true;
    gulp.run('js');
});

As gulp.run is now deprecated, the only way to have a task run other tasks is by specifying them as dependencies. This feels extremely limiting, as the only way to set some logic before running a task is by using command line flags like in this example.

I may have missed it in the issues, but are there plans for programmatically starting tasks other than adding them as dependencies of other tasks?

[timrwood]

Gulp may not solely be a task runner, but the fact that it runs tasks kind of makes it a task runner. I suppose this is just a matter semantics though, so I’ll just consider gulp a thing that has a task runner.

I think the task system in gulp/orchestrator one of gulp’s strengths. Being able to name units of work and reference other named units of work that must happen prior is an excellent pattern.

I understand that you can do essentially what gulp.run did by passing around and calling functions.

The problem I see is that now we end up with is two task systems.

One is formally defined by gulp. It is what is used for running tasks from the command line and from watchers. It has explicit task dependency definitions. It is well tested, and bugfixes are shared with everyone.

The second is informally defined by the user. It may be written with callbacks or events or promises or some other vanilla js. It may or may not have explicit task dependency definitions. It is probably not well tested, and bugs are unique to each re-implementation.

I understand that both of these spaces are going to exist, but removing the ability to start a gulp task from user-land code feels like you are pushing a greater burden onto the user.

Here is a closer representation of what I am currently doing. There are a few more tasks for html, images, and fonts, but this is the gist of it.

var minify = false;

// js-clean and css-clean remove compiled assets
gulp.task('js-clean', function () {...});
gulp.task('css-clean', function () {...});

// js and css tasks use gulp-if to only minify when minify is true
gulp.task('js', ['js-clean'], function () {...});
gulp.task('css', ['css-clean'], function () {...});

// task to build before deployment
gulp.task('build', function () {
    minify = true;
    gulp.run('js', 'css');
});

// task to run while actively developing
gulp.task('develop', function () {
    minify = false;
    gulp.run('js', 'css');
    gulp.watch(jsPaths, 'js');
    gulp.watch(cssPaths, 'css');
});

Without gulp.run, now I need have the develop and build tasks simply call functions that do what the js and css tasks do. But before those functions run, I need to have functions that do what js-clean and css-clean do. Sure, this is possible, but now I have written a one-off task dependency system that cannot hook into gulp’s dependency system.

If I want the two to work together, I need to create hooks for the gulp task dependency system to call my task dependency system rather than the other way around.

Again, all this is possible to do, but it just seems silly to have a task runner bundled with gulp that you cannot use for running tasks and managing their dependencies.

If the reason for deprecating gulp.run was because of user error, do you really think making users implement their own solution is going to result in fewer user errors?

[yocontra]

Just to be clear: the new task system in 4.0 is leagues ahead and much more flexible than the 3.x one discussed in this thread. Check out the docs on the 4.0 branch, you’ll all love it!