Gulp: Request: current task data on `this` within gulp.task fn.

[shellscape]

I'd like to request some additional data on this within a gulp task's fn. It would be very useful to have access to the currently running task without having to iterate over the this.tasks hash to find the task with the running: true flag.

Off the cuff, something like one of the following:

  this.task
  this.current
  this.currentTask

  // nvm uses a similar approach with a symlink of @current pointing at the current ver of node used.
  this.tasks.current;

[pkozlowski-opensource]

@shellscape what is your use-case, functionally speaking? I'm aasking since with Gulp4 you will change so would undersand the functional use-case here.

[shellscape]

A really, really basic use case would be:

// no need to define vars or keep track of the task name

gulp.task('some-task-name', function () {
  console.log(this.task.name);
});

gulp.task('some-other-task-name', function () {
  console.log(this.task.name);
});

// useful for gulpfiles which have many many tasks

Getting more advanced, one could potentially attach static metadata to a task for later use.

[shellscape]

ping

[contra]

@phated Thoughts about binding fn to task when running? I'm voting no for perf reasons, curious if there are any other reasons why/why not

[shellscape]

@contra any information on how this would negatively affect performance? some information to put some weight behind that position would be useful.

[phated]

I'm not going to bind contexts to a function. gulp4 is about reusable function composition and adding context into that takes it so far towards not functional. Also, bind is extremely slow in v8, so that's another reason not to do it. The string task name means nothing anyway, it is just the thing that is called from the CLI.

[pkozlowski-opensource]

I agree with @phated for what it's worth. For now I can't think of a good use-case for having some context bound to this and we haven't heard from @shellscape on his use case (this comment just re-iterates the need but doesn't provide any insight as to _why_ this would be useful).

[shellscape]

@pkozlowski-opensource knowing what task you're presently in is pretty useful. Were you looking for me to provide the entire project we're working on so you can grok that? Custom logging / output for gulp would be one simple and useful example - I thought that was pretty obvious from the simple sample code.

As an aside - it seems like its a lot harder to gain traction with gulp when it comes to suggesting additions, features, improvements - I've run into a lot more friction than I'm used to with other open source projects. I've run into the same thing in gult-util as well. Left wondering if that's the culture within the project and its satellites.

[stringparser]

If I may, I just think that maybe the reason for this is to keep things simple whenever possible and yes, its ok to be upset @shellscape, but understand they are making decisions for the core module. If you want to do your thing you can do it and maybe someone also finds it useful.

One thing that can be done is instead of passing the information at this with the gulp instance pass it as a second argument to the task function, it may involve changing this check though maybe not, I'm not that confident.

[contra]

@shellscape That's because we follow the "small modules" thing. We don't just add features willy nilly, we think a lot about what we add and how much value it brings. If we added every feature that was requested the project would be a heap of shit and nobody would use it. Ascertaining if something is useful or not is a necessity in OSS.

So yes, it is our culture to be really picky about new features and changes. It's done us pretty well IMO

[shellscape]

@stringparser no one's upset fellas. I chose words very carefully to try and be tone-agnostic. @contra it's not my first rodeo, but I get that you might be used to dealing with people who are taking their first ride. Still, pretty brash explanation there man :)

It's useful to know that the project is exceptionally picky. I'll bear that in mind in the future, in a positive sense. I do hope later iterations of gulp are more easily extensible to support advanced usage.

[contra]

@shellscape Not trying to be rude at all, I also chose my words carefully. Just explaining our policy and culture as maintainers. FYI I think you can do this yourself via the task registry in gulp 4 - just bind on register with the task info. We keep the core small but make sure things are extensible so features like this are possible, just not included by default. Let me know if you run into any issues doing this in gulp 4 (docs, stuff not being exposed) so me or @phated can assist

[phated]

@contra this use case and many others will be customizable through custom undertaker registries. I can probably do another proof of concept using this bind request.

[phated]

I've finally gotten around to making this POC registry. See https://github.com/undertakerjs/undertaker-task-metadata/blob/master/examples/gulpfile.js for an example gulpfile. I also needed to update undertaker to get everything to work and it hasn't been published yet. Just wanted to show the progress.

[bmacnaughton]

I'd like to run the idea that the task should be available by you one more time. I did run your linked example and see that the name of the task is available there. So my question is more whether it makes sense to provide the name by default or whether to require the registry to be set up.

Here's an excerpt of my gulpfile.js - there are 22 tasks defined in it. Maybe I'm thinking about this all wrong and I don't need the duplicate task names, so your thoughts on that are welcome. The key point is that each task is unique in terms of the .pipe() steps that need to be executed. Even though all the task names are right there it seems that one fails to get updated with some consistency (though that might just be my issue).

gulp.task('framework-css', function() {
    return gulp.src(wf['framework-css'].get(target))
        .pipe(autoprefixer())
        .pipe(rename(v2cssTarget))
        .pipe(gulpif(optMinify, nano()))
        .pipe(gulpif(optMinify, rename({extname: '.min.css'})))
        .pipe(filenames("framework-css"))
        .pipe(chmod(0o664))
        .pipe(gulpif(debugging, debug({title: 'framework-css', verbose: true})))
        .pipe(gulp.dest(paths.wf_css.dest[target]));
});

gulp.task('framework-js', function() {
    return gulp.src(wf['framework-js'].get(target))
        .pipe(gulpif(optConcat, concat(paths.wf_js.concatname)))
        .pipe(gulpif(optMinify, uglify({preserveComments: 'some'})))
        .pipe(gulpif(optMinify, rename({extname: '.min.js'})))
        .pipe(filenames("framework-js"))
        .pipe(gulpif(debugging, debug({title: 'framework-js'})))
        .pipe(gulp.dest(paths.wf_js.dest[target]));
});

I don't really care that it's available on this. Just having a function gulp.getTaskName() would work fine; I'd call it once in the gulp task and retain the value in a closure.

[noah79]

How can something this basic not be a part of the API? Shit's crazy, yo.

[phated]

@noah79 this has been heavily discussed and we don't clutter the API with things that can be pushed to the edges (where edge-cases belong). Please refrain from these sorts of comments on the issue tracker, as it just produces more noise.

[jaworskm]

To get the task name can we just use Node? Can this solution be improved?

const TASK = _.head(process.argv.slice(2, 3));

[cronfy]

Here is my use case:

I have several tasks in gulpfile.js and I have external local project config in gulp-tasks-config-local.js:

Gulpfile:

gulp.task('build', function() {
    var config = { dest: 'web/ui' }
    ...
})

gulp.task('test', function() {
    var config = { tests: 'all' }
    ...
})

Local config:

modue.exports = {
    build: { dest: 'web/new/ui' },
    test: { tests: [ 'test-group-1', 'test-group-2' ] }
}

Now I want to do this in gulpfile's task:

config = merge(config, localConfig[this.TASKNAME])

But current task name is not available. How would I achieve this?

[jaworskm]

In my common configuration file for my gulp configuration I set and export significant variables for other configurations like rollup.js and you could do the same for your js file.

In my configuration file which is common to my gulpfile.js and all other task files:

process.env.GULP_TASK = _.head(process.argv.slice(2, 3));

In your js file which needs the variable:

config = merge(config, localConfig[process.env.GULP_TASK]);

[cronfy]

@jaworskm It won't work if configuring task's dependencies is also required:

gulp.task('all', ['build', 'test'])

no way to specify config for build and test by it's name, when gulp all is executed.

[jaworskm]

Maybe I don't follow, but if you want to share something more complex than a string I just JSON.stringify and parse on the receiving end.

[cronfy]

No, let me try to explain it with more detailed example:

Local config:

// local-config.js

module.exports = {
    build: { dest: 'web/new/ui' },
    test: { tests: [ 'test-group-1', 'test-group-2' ] }
}

Gulpfile:

const local_config = require('local-config.js');

gulp.task('build', function() {
    const default_config = { dest: 'web/ui' }
    const override = local_config[this.TASKNAME] // <-- here is where I need task name
    const config = merge(default_config, override)
    ...
})

gulp.task('test', function() {
    ...
    const override = local_config[this.TASKNAME] // <-- here is where I need task name
    ...
})

gulp.task('all', ['build', 'test'])

When I run gulp all, I need build's and test's overrides to be populated from local_config by task's name.

[cronfy]

Not that way...

gulp.task('build', function() {
    console.log(this.TASK);
})

gulp.task('test', function() {
    console.log(this.TASK);
})

gulp.task('all', ['build', 'test'])

gulp all should output:

test

In your example it will output:

all

[jaworskm]

That would be a requirement for the gulp team.

[phated]

Custom registries in gulp 4. Locking.