-
-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Config option to multiple command-line tasks in series #93
Comments
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 I'll leave this open incase others have opinions. |
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. |
We are kinda going overboard with flags. Maybe this could be configurable in the new |
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 Or I could always have bash handle this ( |
@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). |
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 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 |
We aren't currently supporting traversal but we support merging config from |
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. |
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 :-) |
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 |
Don't think I have a strong preference either way... |
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:
series
call, instead?series
?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
The text was updated successfully, but these errors were encountered: