gulp ships four dependencies and a bin, and puts every task in a gulpfile you write

The core is four dependencies and a bin that hands off to gulp-cli

What npm calls gulp 5.0.1 is a thin shell. Its four runtime dependencies are glob-watcher ^6.0.0 for the watch side, vinyl-fs ^4.0.2 for reading and writing files, undertaker ^2.0.0 for running tasks, and gulp-cli ^3.1.0. The published file list is just LICENSE, index.js, index.mjs, and the bin directory, and package.json maps the binary to ./bin/gulp.js. The practical consequence is that installing gulp does not install a Sass compiler, a bundler, or a minifier. Everything that actually transforms your files arrives as a separate package, and the project's pitch leans on that: more than 3000 curated plugins exist for streaming file transformations. The core supplies plumbing, and your gulpfile supplies the entire build, so the size of a new gulp install tells you nothing about the size of the pipeline you will write.

The same build exists in two module systems, chosen by how you name the file

There are two entry points and the choice is yours. The CommonJS sample opens with `var gulp = require('gulp');` and pulls in gulp-less, gulp-babel, gulp-concat, gulp-uglify, gulp-rename, gulp-clean-css, and del. The modern sample imports the same tools as ES modules, taking `src`, `dest`, and `watch` straight from gulp itself, and pulling `deleteAsync` out of del. You activate that version either by naming the file gulpfile.mjs or by setting "type": "module" in your package.json, because gulp loads a wrapper for your ESM code. Under the hood the exports map sends import to ./index.mjs and require to ./index.js. The consequence for a team mid-migration is concrete: a project on "type": "module" cannot paste the older gulpfile in unchanged, and the same repo can end up with two gulpfiles that drift apart unless you pick one.

Incremental builds buy you one watch session, then forget everything

gulp offers a way to skip unchanged files through the `since` option on `gulp.src` paired with `gulp.lastRun`, which records when a task last finished.

function images() {
  return gulp.src(paths.images.src, {since: gulp.lastRun(images)})
    .pipe(imagemin())
    .pipe(gulp.dest(paths.images.dest));
}

function watch() {
  gulp.watch(paths.images.src, images);
}

The catch is stated plainly: task run times are saved in memory and are lost when gulp exits, so this only saves time during the watch task when you run the images task a second time. A one-shot build gets no benefit at all, and each restart of the CLI starts from zero. If your images task is slow and you only build on demand rather than watching, the feature you would want, a persistent cache, is not in this repository.

A gulpfile is just another node program, and the return value is the contract

The comment inside the sample gulpfile is the most useful line in it: not all tasks need to use streams, because a gulpfile is just another node program and you can use all packages available on npm. The sample obeys that. Its cleanup task is an exported arrow function that hands back a promise rather than a stream.

export const clean = () => deleteAsync([ 'assets' ]);

The CommonJS comment trails off mid-sentence at "but it must return", and that unfinished clause is the part that bites. Whether you return a vinyl stream, a promise from a package like del, or something else, returning is what tells the runner there is work in flight. A task that computes something and returns nothing looks finished immediately, and the next task in the series starts while the previous one is still writing. The plugin ecosystem is where this matters most: every gulp plugin is expected to hand back a stream, so a plugin that returns undefined quietly breaks the chain.

Both documentation links point at the same quick start page, and the project says the rest is behind

The Installation section is one sentence long: follow the Quick Start guide. The Documentation section points at a Getting Started guide and API docs on the website, and both of those links resolve to the same quick start URL, https://gulpjs.com/docs/en/getting-started/quick-start, while the API reference lives at /docs/en/api/concepts. Underneath both, the README carries an apology: excuse our dust, all other docs will be behind until everything gets updated, and readers are asked to open an issue if something is not working. The consequence is that in-tree answers to behavior questions may not exist, even though a docs/ directory sits in the repository root. Treat the website as the reference, treat a missing answer as something to file rather than something to infer, and do not assume the docs/ folder is a maintained copy of the published guides.

No install line at the root, and a Node floor that predates most current tooling

There is no copy-paste installation command anywhere in the README, so the route in is the npm package page or the quick start guide. What the metadata does pin down is the runtime contract. The engines field asks for Node >=10.13.0, the license is MIT, and the homepage is gulpjs.com. That floor is the price of an API surface that has stayed deliberately small, and it is the first thing to verify when a gulpfile will run in CI, in a container, or inside someone else's build. The repository also keeps its own house rules visible at the root: .editorconfig, .eslintrc, .prettierignore, .gitattributes, a .npmrc, and a .tidelift.yml next to EXPENSE_POLICY.md. Development itself is one lint call and one coverage call.

"scripts": {
  "lint": "eslint .",
  "pretest": "npm run lint",
  "test": "nyc mocha --async-only"
}

The last commit is February 9, 2026, and the shipped version is from June 2025

The published versions are v5.0.1 on June 1, 2025, v5.0.0 on March 29, 2024, and v4.0.2 back on May 6, 2019, and the most recent push to master is dated February 9, 2026. Read together, those dates describe a project whose API is settled and whose release cadence is slow, not one that is shipping features weekly. The test and lint stack behind it is pinned the same way: eslint ^7.0.0 with eslint-config-gulp ^5.0.0 and eslint-plugin-node ^11.1.0, mocha ^8.0.0, nyc ^15.0.0, expect ^27.0.0, and rimraf ^3.0.0, with coverage reported as lcov plus a text summary from the test directory. If you need a bug fixed in gulp itself rather than in a plugin, the practical question is who maintains the plugin you depend on, because the core and the 3000 plugins move at different speeds.

Editorial conclusion

gulp fits teams that already think in streams and want each build step to be a small npm package they can swap. It does not fit a project that wants a documented, batteries-included opinion, because the core holds no task implementations and the project itself says its other docs are behind. Before committing, open a gulpfile on your real file set and check the return value of every task, and confirm your Node version still clears the declared floor of 10.13.0.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes