Update Gulp 4 recipe for splitting tasks between multiple files
See original GitHub issueTL;DR - Define composite tasks in gulpfile
after gulp.registry(hub)
Split tasks across multiple files has been updated to use the new gulp-hub
module, but with the Gulp 4 registry forward referencing tasks is no longer possible.
While sequencing is still being discussed in #972 and (prior to that) #802, I’ve created a test repo with a basic example of splitting tasks across multiple files with a slightly modified recipe.
https://github.com/bradcerasani/gulp-4--split-tasks
Description
Standalone tasks are defined in the tasks
directory, and gulp-hub
is used to create a new registry. Tasks that use a combination of sub-tasks are now defined in the gulpfile, after gulp.registry
While this will require a minor restructuring of tasks in some projects, I actually prefer defining composite tasks like default
, watch
, and build
in my gulpfile
and using the tasks
directory strictly for standalone tasks. In larger gulpfiles composite tasks are typically short and called far more frequently than their standalone siblings, so IMO it’s easier to reference them in one place.
File structure (unchanged):
gulpfile.js
tasks/
├── clean.js
└── scripts.js
gulpfile.js
'use strict';
var gulp = require('gulp');
var HubRegistry = require('gulp-hub');
// load some files into the registry
var hub = new HubRegistry(['tasks/*.js']);
// tell gulp to use the tasks just loaded
gulp.registry(hub);
// define composite tasks
gulp.task('default', gulp.series('clean', 'scripts'));
If this is a viable solution, I’m happy to submit a PR with an updated recipe.
Issue Analytics
- State:
- Created 8 years ago
- Comments:15 (7 by maintainers)
Top GitHub Comments
Please stop spamming our projects. An upgrade path has already been developed.
@phated, I really appreciate you putting thought into my case, though I just don’t understand the reasoning behind the current implementation. As it stands, I’d rather just monkey-patch .series and .parallel for lazy task lookup because it’ll also allow me to load a directory of tasks, which is another big convenience of how I do things now. But maybe I’m just missing something? I’d love to hear your reasoning for early task lookup rather than at runtime.
(My own gulp3-based .parallel and .series functions accept regex objects for lookup at runtime. This way, my build task does /build…*$/, which for some projects matches the global “build.css” and “build.js”, but in particular projects also matches the local “build.font” or “build.html” in their local tasks directories.)