Config option to multiple command-line tasks in series

[erikkemperman]

It isn't really explicitly documented that commandline tasks will be run in parallel, unless I missed something... But I guess users of almost any other build tool would expect them to be done in series. E.g., gulp clean build seems like a common scenario.

So I was wondering:

• should the default be to run commandline tasks in a series call, instead?
• if not, should there maybe be an option to run tasks in series?
• either way, should this be documented more explicitly?

Thanks, I hope it's not a silly suggestion...

Ref. https://github.com/gulpjs/gulp-cli/blob/master/lib/versioned/%5E4.0.0/index.js#L77

[phated]

The concept of gulp has always been to run everything at "maximum concurrency" and I think that is the proper behavior to propagate to the CLI. The recommended way to run gulp is with a single task (or, more likely, none for default), even though we support multiple. I agree that this could be documented better (like many things in gulp).

I'll leave this open incase others have opinions.

[yocontra]

Yeah, we should document this better. The right way to do this would be a new task that runs those two in series, but I could see how this is confusing.

That said, I don't think a flag would be terrible here to reduce boilerplate.

[phated]

We are kinda going overboard with flags. Maybe this could be configurable in the new .gulp.* configuration files.

[erikkemperman]

Yeah, coming from gulp3 I guess it won't be unexpected, but now that there's undertaker in place of orchestrator people have to compose with series/parallel explicitly anyway, and I thought it might make sense to extend that to the top (cli) level.

Coming from any other build tool it might cause some confusion initially.

Of course I can just make special tasks -- actually looking at some clutter in my own gulpfiles (tasks like cleanbuild) made me wonder about this.

Or I could always have bash handle this (gulp clean && gulp build). But maybe an option or config to change the cli composition might make some sense.

[phated]

@erikkemperman I typically defer "conditional" tasks (like clean) to flags and then have code that generates the sequence inside the gulpfile.

> gulp build --clean

gulp.task('build', (argv.clean ? gulp.series(clean, build) : build));

Or something similar.

Deferring to bash is also a good idea but the CLI startup time might be really slow (not sure).

[erikkemperman]

Ah, that's a nice pattern. No wonder you're hesitant to have the cli claim options 👍

Yes, I'd expect node startup overhead twice with &&, which is unfortunate.

I hadn't looked at the new config file support before, nice!

Sorry for off-topic, but is it silly to expect that to work like .editorconfig and traverse up from current directory looking for config files? It might be handy for multi-module projects. Did you have a rule of thumb in mind as to what should be a cli option vs config item? (The only current config option, project description, seems slightly unsuitable for global use in ~/.gulp.json, imho).

[phated]

We aren't currently supporting traversal but we support merging config from cwd and from home.

[phated]

We just added the config file stuff (it hasn't even been released yet), so there's no hard rule on what belongs where. All CLI flags will be able to be defaulted in the config file but I don't want to add lots of CLI flags if it makes sense to be part of a config file. My initial thoughts are "if you would have to abstract the gulp command behind an npm-script, e.g. gulp clean build --series, then it should probably be a config option instead", but I'm not totally set on that.

[erikkemperman]

I was thinking a guideline might be, is this thing specific for the project, or for just the next build I want to trigger? Or is that basically what you were saying?

Nice twist to have defaults for options from config, I hadn't noticed that bit yet. So I guess shouldn't think about options vs config in terms of either/or :-)

[phated]

Now that we shipped config files. What should this property be named in the config file? Should it be a top-level key or inside a nested object? @erikkemperman @sttk

[erikkemperman]

Don't think I have a strong preference either way...