Gulp 4's Stream Pipeline: When Code-Over-Configuration Still Wins

Your build config has grown into a 400-line declarative object, and adding one conditional step means reading plugin docs instead of writing JavaScript. That's the pain Gulp was designed to remove, and it's still a reasonable choice in 2026 for one specific job: transforming files that aren't JavaScript modules. The useful takeaway: Gulp's stream pipeline plus gulp.lastRun gives you fast, incremental asset builds with plain code — as long as you target Gulp 4 explicitly and don't ask it to bundle your JS.

Streams instead of temp files

Gulp's defining idea is that a build is a pipe, not a sequence of disk writes. gulp.src() emits vinyl file objects — lightweight wrappers around a file's path and contents — and each .pipe() step transforms those objects in memory. Nothing touches disk until gulp.dest() writes the final output. Older configuration-driven tools wrote intermediate files between every step, which meant more I/O and more config to describe where the temp files lived.

The practical consequence: a Sass → autoprefix → minify chain is three function calls in sequence, and you can insert a conditional step with a normal if statement instead of learning a config schema.

Tasks are functions, and Gulp 4 made order explicit

A Gulp task is an exported JavaScript function. Gulp 4 replaced the old Gulp 3 dependency-array model with two combinators: gulp.series() runs tasks one after another, and gulp.parallel() runs them concurrently. Execution order is visible in the code rather than implied by a dependency list.

This matters because a lot of older tutorials and Stack Overflow answers are written for Gulp 3 and will fail under Gulp 4 with task-not-found or signature errors. Everything below assumes Gulp 4 (check with gulp --version; you want CLI and Local both at 4.x). Run that in your project root after npm install --save-dev gulp; no elevated permissions needed.

A worked example: Sass to minified CSS, incrementally

This gulpfile.js compiles Sass, autoprefixes, minifies, and watches for changes. Place it in the project root alongside src/scss/:

const { src, dest, watch, series, lastRun } = require('gulp');
const sass = require('gulp-sass')(require('sass'));
const autoprefixer = require('gulp-autoprefixer');
const cleanCSS = require('gulp-clean-css');
const plumber = require('gulp-plumber');

function styles() {
  return src('src/scss/**/*.scss', { since: lastRun(styles) })
    .pipe(plumber())
    .pipe(sass().on('error', sass.logError))
    .pipe(autoprefixer())
    .pipe(cleanCSS())
    .pipe(dest('dist/css'));
}

function watchStyles() {
  return watch('src/scss/**/*.scss', series(styles));
}

exports.styles = styles;
exports.default = series(styles, watchStyles);

Two details do the heavy lifting:

• { since: lastRun(styles) } filters the source set to files changed since the styles task last ran. On a large asset tree this is the difference between a watch loop that feels instant and one that reprocesses hundreds of files per keystroke. One caveat: lastRun only records a timestamp when the task is invoked through Gulp's runner, so it works in the watch flow above but not if you call the function directly.
• plumber() intercepts stream errors so a Sass syntax error logs a message instead of killing the watch process. Without it (or explicit .on('error') handlers on every step), one typo ends your dev session.

Run npx gulp from the project root. You should see dist/css/ populate. Then edit one .scss file and check timestamps with ls -l dist/css/ — only the affected output should update. Run npx gulp --tasks to confirm the exported task graph matches what you expect.

The honest trade-off: Gulp is not a bundler

Gulp orchestrates file transformations; it does not resolve JavaScript module graphs. If your problem is "bundle ES modules, code-split, and tree-shake," the right tool is esbuild, Rollup, or webpack — not a gulp plugin wrapping one of them. Wrapping a tool that already has a good CLI often adds indirection and a stale dependency for no benefit.

Where Gulp still earns its place: non-JS asset pipelines (CSS, images, fonts, static-site assets), or as the task runner around a bundler invoked directly. Also check plugin maintenance before committing — some gulp-* packages are thin, unmaintained wrappers. A quick look at the npm page's publish date and open issues is worth the thirty seconds.

Try it, then measure

Pin Gulp 4, copy the example above, and verify two things yourself: that dist/css output is correct for your Sass, and that since actually skips unchanged files in your tree (file timestamps or a gulp-debug step will show you). If the incremental watch loop is fast and readable, keep it. If you find yourself fighting plugins to do module bundling, that's the signal to reach for a bundler instead.