list tasks as json

[segrey]

Now gulp tasks could be listed using --tasks or --tasks-simple arguments.
Passing --tasks argument lists tasks in a human readable format that cannot be easily parsed in code (gulp integration in IDE).
Passing --tasks-simple argument lists one task per line, but has the only downside: any output other then task will be considered to be a task name. For example, placing console.log('hello') as the top level in a gulpfile will result in having hello task.

Is it possible to add a new argument that will output tasks as json? Thanks.

[sindresorhus]

You would still have the problem even if it were JSON.

I think gulp should just disable stdio of the gulpfile when --tasks and --tasks-simple is used.

[segrey]

Thanks for the quick answer.

You would still have the problem even if it were JSON.

If json text would occupy a single line, then it would be possible to iterate over lines and check whether a line is the needed one.

I think gulp should just disable stdio of the gulpfile when --tasks and --tasks-simple is used.

That would be nice and backward compatible.

[segrey]

One more idea: insert two unique lines right before and after task name lines, like:

regular output
@start listing tasks@
default
connect
my task
@end listing tasks@
other output

Also that would allow IDE to forcibly terminate node process in case of #583.
This behavior could be triggered by passing a new argument (e.g. --delimit-task-list).

[yocontra]

Do you have a case where this actually happens? If you pass a task list then your gulpfile will not be executed, which means nothing should get logged. If you have logging outside of your tasks you should move it. I will reopen this if you have a legit usecase

[segrey]

Yes, the case is logging outside tasks. Maybe some initialization logic could be placed there. It isn't guaranteed that it won't happen in users' gulpfiles.

[stringparser]

Why not create a task to write a file in a non-human readable format? i.e. json?

gulp.task('log:tasks.json', function(){
  var ws = fs.createWriteStream('tasks.json');
  var tasks = gulp.tasks;
  ws.write(
    JSON.stringify(tasks, function(key, value){
      if(typeof value === 'function')
        return ''+value;
      else
        return value;
    }, ' ')
  );
});

[phated]

not sure how this would happen since the task listing happens on nextTick...

[segrey]

JFYI: IDE uses --tasks parameter to fetch task information.
Using --tasks instead of --tasks-simple allows to fetch task dependencies and show it for user.
Another benefit is that logging outside tasks can be filtered out with a high probability, because a line with task/dependency should contain pseudographics.
The only downside of using --tasks is parsing pseudographical tree. :)

[segrey]

About gulp.task('log:tasks.json', function(){...}) task:
IDE cannot modify user's gulpfile. Also gulp doesn't allow to pass more than one gulpfile.
BTW, Grunt allows to specify tasks in several files, so WebStorm Grunt integration uses this approach to list grunt tasks.

[stringparser]

Yep, this should work better.

But then, if you can't have a handle on the same gulp instance it won't really work. Though you can make a plugin that will be on the same local directory of the user and maybe that can work.

var gulp = require('gulp');
var timer;
gulp.on('task_stop', function(e){

  if(timer)
    clearTimeout(timer);

  timer = setTimeout(function(){
    if(e.task !== 'log:tasks.json'){
      gulp.start(['log:tasks.json']);
    }
  });
});

[phated]

in gulp4, we are adding a tasks method that returns the task tree in a format compatible with archy. Should solve all these problems.

[segrey]

@stringparser Sorry, I'm not sure the approach with plugin will work, because the plugin should be required from the user's gulpfile, right? Also in order to run 'log:tasks.json' task some other task should be executed.

[segrey]

@phated Thanks for letting me know. I've checked out gulp4. It turned out that IDE integration still works, but passing --tasks parameter doesn't print task dependencies anymore. Is it possible to preserve old output format where task dependencies are also logged? Thanks.

[segrey]

@phated Did you mean require('gulp').tasks() or --tasks command line parameter?

[phated]

@segrey --tasks still works if the gulpfile and local gulp are updated to reflect breaking changes but we are also exposing require('gulp').tasks() for tools that would rather have a json representation (like the archy module which is used in the CLI)

[phated]

Note, the liftoff + requiring a gulpfile dance will still be needed for tasks to return anything.

[segrey]

@phated My apologies. You're right, --tasks works. The tree just has one more level. I'll update the IDE parser to reflect the changes. Thanks.
About using require('gulp').tasks(): current stable gulp (as of now 3.8.7) also allows to use require('gulp').tasks. Well, it just feels wrong to copy&paste logic from bin/gulp.js and use gulp's internal dependencies directly. IMO, doing it in this way will make task listing more tightly coupled to gulp internal implementation. So, I decided it'd be better to parse pseudographical tree. Parsing the tree isn't the best way either. Computer readable gulp --tasks would be convenient for other tools too, not only WebStorm.

[yocontra]

I think --json should be added in gulp 4 to output gulp.tasks()

[segrey]

Guys, I think I need to provide more details why using require('gulp').tasks doesn't seem to me to be a good idea.
Before iterating over require('gulp').tasks the following things should be done:

1. Finding a local gulp package.
2. Loading needed modules for extensions (.coffee/.jsx/etc).
   Here liftoff and interpret gulp dependencies should be required and used. To require these packages, resolve package is needed.
   As the local gulp package is found, it's possible to iterate over require(localGulpPackage).tasks and dump json.
   IMO, requiring internal dependencies of a package isn't reliable enough and should be avoided.

[yocontra]

@segrey I already told you I would add it 😕 please read my previous comments before posting more - I understand exactly what you are saying and I agree with you

[segrey]

@contra I did what you asked me in #472 (comment)
Sorry, your agreeing with me wasn't obvious for me, because you asked about repeating logic and said that --json should be added in gulp4 simultaneously.
Anyway, I hope it was worth to provide here the details about using require('gulp').tasks for other participants.

[yocontra]

@segrey Sorry for not being clear - I am putting --json on the roadmap. Thank you for adding more details for people who weren't in the other issue

[phated]

Added in 4.0 branch. Try it out. Flag is --tasks-json to stay inline with --tasks-simple

[segrey]

Cool, thanks!
How about not listing dependencies of task dependencies (i.e. dependencies of second level or higher)?

Example:

var gulp = require('gulp');
gulp.task('a4', function () {});
gulp.task('a3', gulp.series('a4'));
gulp.task('a2', gulp.series('a3', 'a4'));
gulp.task('a1', gulp.series('a2', 'a3'));

Listing all dependencies deep inside may lead to exponential growth of output.

BTW, gulp support is available in WebStorm 9 EAP, 138.1988.

[yocontra]

tasks-json was added but the issue not closed for some reason. Closing this.