Welcome to our freshly relaunched blog! You may have noticed that we are now directly hosting our blog on the gulpjs.com domain.

In a world of corporations obsessed with the enshittification of their platforms, the gulp team is methodically moving away from platforms we don’t control. One of the easiest places to change was self-hosting the blog on our own infrastructure instead of relying on Medium.

We’ve migrated our old posts from Medium and plan to release a series of posts about our current development efforts leading up to v6. So please subscribe (rss, atom) with your favorite reader software to stay updated!

The Gulp Developer Survey is officially closed. We want to thank each and every one of you who completed the survey! In total, we received over 600 survey responses and are excited to review what everyone has to say.

Without the editors who graciously shared the survey link with their readers, we know we would not have had such a good turn out. So shout out to the following newsletters for including the Gulp Developer Survey:

✨ Web Weekly — “Your friendly web dev newsletter.”

✨ JavaScript Weekly — “A newsletter of JavaScript articles, news and cool projects.”

✨ Codrops Collective — “Weekly news about qualitative new projects and libraries in web development and design.”

✨ The Repository — “What’s happening in WordPress — and what everyone’s saying about it.”

✨ JAMstacked — “An email update on the evolving web development ecosystem.”

✨ Console — “A free weekly email digest of the best tools for developers.”

✨ The WP Weekly — “The Weekly Newsletter for WordPress Professionals.”

If you’re missing out on developer happenings, we highly recommend checking out these wonderful sources!

Over the next few weeks, I will be cleaning and analyzing the data for the Gulp team. We will be sharing the results here as soon as they are finalized, so keep your eyes peeled for the next blog post if you consider yourself a #dataisbeautiful nerd like myself. 🤓

Photo by Aaron Burden on Unsplash

Keep it Simple 🤝​

Gulp has come a long way since its humble beginnings a decade ago. In that time, gulp has remained dedicated to simplicity despite the competition for “one tool to build them all.” The gulp team has a clear mission, and they want to do it well. The v5 release ushers in a new phase of gulp development, and to that end, they’ve decided to work with me to seek feedback from the gulp community. Many tech communities for tools, frameworks, and beyond host a “State of” survey regularly, and gulp is now joining the fray.

Who Am I? 🙋🏽‍♀️​

Hi, I’m Claire! I recently started working with the gulp team to guide them through creating, deploying, and analyzing their developer survey. I have a background in academia as well as non-profit education and leadership. I am excited to be applying my research skills to the needs of the gulp team as I enter the open source realm.

The Survey ✍️​

We invite you to help us explore the needs of the gulp community above and beyond the issues on GitHub by completing the Gulp Developer Survey before May 31st. Your responses to the survey will provide the gulp team with valuable insights in future directions, features, and long-term sustainability.

Quick Facts

✨ The Gulp Developer Survey is available on desktop, tablet, and mobile.

✨ The survey is anonymous.

✨ It takes the average participant ~15 minutes to complete the survey.

✨ We’re inviting responses from everyone: current users, previous users, professional users, new or interested users, and all folks in between.

✨ Most questions are multiple choice; however, there are a few open ended questions and we invite you to use those to share your ideas with the team.

✨ There is only one required question, so all other questions are optional.

✨ This year’s survey is only available in English, but we’ve included a question to understand what other languages our global community needs for the future.

Opt-In (or don’t 👍)​

At the end of the survey, you will be redirected to a page to collect an email address if you are interested in any follow-up participation. This is completely optional and is not connected to the survey to keep your responses anonymous. It is a space to opt-in to contact if we decide to host more personal feedback sessions such as focus groups or interviews. Numbers only get us so far and we recognize how tedious open ended questions can get, which is why we limited them. Regardless, we totally understand if you don’t want your email on another list.

Final Words 🗺️​

The last day to complete the Gulp Developer Survey is May 31st. We encourage you to share it out to your communities however you please. In the spirit of open source, we really can’t do this without you! So whether you use the new version, an old version, or have moved away from gulp entirely, we hope you’ll take the time to contribute to the project’s future direction. Once the results are collected and analyzed, we’ll share them out with everyone here on the blog. We are excited for the ideas your feedback will bring, and we look forward to going on this adventure with you.

TAKE THE SURVEY HERE

It’s been a long road to gulp 5, but we’re finally here! This release contains four years worth of work on over 60 projects. Together, the team has closed over 200 issues and pull requests. 🤯

Streamx​

From the very beginning, gulp has been built around streams. In gulp 5, we’ve switched over to mafintosh’s excellent streamx library. Streamx has many advantages over Node.js core streams, including handling both object and buffer mode transparently and error handling on the pipe() function.

We hope to find time to do more writing about this delightful stream implementation, but most users shouldn’t notice a difference because streamx strives for compatibility with Node.js core streams. We want to thank Mathias for his help and bug fixes throughout the development of gulp 5! Please consider sponsoring his work.

Dependencies​

A primary focus of this release was reducing our dependency tree and consolidating it to mostly things we maintained. Many dependencies we previously used became unmaintained since gulp 4 was released, so we’ve either removed them or taken on maintenance responsibilities.

The gulpjs GitHub organization has grown to over 70 repositories. This fine-grain separation allows us to make small fixes quickly, and many other projects can rely on a subset of our packages. However, the trade-off is that it takes awhile for us to make sweeping changes across the project.

Breaking changes​

It wouldn’t be a SemVer major release without breaking changes. We hope these breaking changes cause little or no problems when users upgrade, but you should be aware of what has changed.

With such a large release, I’m only scraping the surface on the changes here, so please check out both our combined changelog and individual project changelogs if you encounter anything that seems different.

Stream encoding​

Our streams now default to UTF-8 encoding. Previously, our streams took whatever data was emitted without considering any encoding. However, in this release, we resolved a 10 year old issue to support custom encodings and we default these to UTF-8. Most usage of gulp won’t need to change anything, but certain plugins may produce non-UTF-8 output and you’ll need to set { encoding: false } on your gulp streams.

Globs​

We’ve also standardized our globbing library across all APIs. Previously, src() used the node-glob library and watch() used the anymatch library via chokidar. Over the years, we’ve had many issues opened because certain globs didn’t work the same between these functions. As of gulp 5, we consistently use anymatch for glob support.

Additionally, we no longer support “ordered globs”. An “ordered glob” was the ability to apply globs in order, such that a negative glob could be overridden by a positive glob that came later in the array. This isn’t common in other globbing libraries, so all negative globs will filter paths from all positive globs to standardize with the ecosystem. If you need ordered streams, we provide the ordered-read-streams library.

CLI​

We’ve added loaders for swc, esbuild, and sucrase. A lot of users asked us to support .mjs and .cjs extensions, so both of those are available now. In streamlining our dependency tree, we’ve removed a lot of legacy and deprecated loaders. If you were using some of the more obscure loaders we supported, you may need to change to something more modern.

We’ve finally removed the --verify flag since we stopped maintaining the plugin banlist a long time ago, and we needed to rename --require to --preload to avoid conflicting with a Node.js flag.

Logging​

Any plugins using gulplog will need to upgrade from v1 to v2 and we’ll emit a deprecation warning if v1 is used.

Node Support​

We’ve long said that gulp is stable software, and we care about supporting as many users as possible. Gulp 4 had an explicit goal of supporting users on Node.js v0.10 because it was widely used at the time of release. Ten years later, the platform has grown and JavaScript has evolved, Node.js now has new stable releases every 6 months with an LTS duration of 30 months on any version. These new versions have features we want to leverage to make gulp better and even more stable, so we’ve dropped support for any version of Node.js below v10.13.0.

Constraining our supported Node.js version has allowed us to drop a lot of platform and JavaScript shims from our dependency tree. A lot of these have gone unmaintained or cause issues to be raised by scanners. We’re still supporting a version of Node.js released in 2018 (and outside of the LTS window) in hope that all our users can upgrade to gulp 5 smoothly.

Finally, we’ve had a fair bit of churn on our infrastructure between v3, v4, and v5 because we have long considered Windows, Mac, and Linux to be priority platforms. It took a long time to find a continuous integration service that consistently supported all these operating systems and was easy to use. We’ve spent considerable time stabilizing our infrastructure around GitHub Actions, which has support for our primary targets and allows us to leverage tools like release-please.

Onward​

There is always more work to be done. In the coming weeks, I’ll be triaging our post-v5 project board and creating a discussion for non-breaking follow up work. We plan to keep gulp 5 stable for a while before we begin planning the next major version, which will allow us to patch any problems that come up.

We’re also putting together a survey to get feedback from the broader community. Keep an eye out for our announcement around May.

For now, we hope you enjoy the new release and welcome you to contribute to the project or sponsor our work!

For the past year, version 4.0 has been published to npm and could be installed using npm install gulp@next. Today, it’s being promoted from “next” to “latest” which means it will be installed by default when you run npm install gulp. With this, all previous versions are soft deprecated and will become hard deprecated in the coming months.

What’s new in 4.0?!​

• The task system was rewritten from the ground-up, allowing task composition using series() and parallel() methods
• The watcher was updated, now using chokidar (no more need for gulp-watch!), with feature parity to our task system
• First-class support was added for incremental builds using lastRun()
• A symlink() method was exposed to create symlinks instead of copying files
• Built-in support for sourcemaps was added — the gulp-sourcemaps plugin is no longer necessary!
• Task registration of exported functions — using node or ES exports — is now recommended
• Custom registries were designed, allowing for shared tasks or augmented functionality
• Stream implementations were improved, allowing for better conditional and phased builds

We’ve written a new Getting Started guide and API docs to smooth the transition between versions. We hoped to have updated recipes, advanced topics, and a migration guide written before this release, but have yet to secure funding to finish them.

If your company is interested in funding the future of gulp documentation, let us know!

Working on gulp in the Andes.

Congratulations on the Gulp release! What would you say your favorite feature is?

Thanks!

Oh, wow — there’s just so much! Most people will really enjoy and benefit from gulp.series and gulp.parallel; however, I really like exporting tasks and incremental builds.

I’m going to be giving a talk in February about all the new features; watch the gulp twitter for the slides in a few weeks.

It’s been in development about 3 years. What took so long?

For a lot of the development time, I’ve been the only person working on it. Within the last year or so, a few people (shoutout to erikkemperman, sttk, and the rest of our core contributors) have come in to help out on some of the stickiest problems. They’ve also really kept me motivated.

Working on something this big, by myself, it’s really easy to burn out. This has pretty much been my only (unpaid) job for a year. I definitely burnt out multiple times during the development process and had to step away. It’s much more enjoyable to work on a project when other community members are involved.

Gulp is always looking for contributors. Soon, we’ll be rolling out a process to onboard people to the core team to take on parts of the project.

Open Source is driven by community involvement. What do you need help with right now?

We REALLY need help with documentation. That’s our biggest thing right now. All of our dependencies have been fully documented, but none of it has been pulled into the main repo & contextualized for gulp.

Of course, there are some bugs that are being sorted out. I just fixed a frustrating one this week — you shouldn’t see “Premature Close” errors anymore. If you encounter a bug, definitely let us know, with as much detail as possible.

Demurgos and other community members have made a ton of progress on the gulp-util migration. But there’s still a lot of work to do because many plugins don’t function properly with gulp 4. (Editor’s Note: see The Problem with gulp-util to help out.)

When I install gulp, I get version 3.9.1. Why don’t I get 4.0.0 by default?

While it’s published to npm, you have to use the command npm install gulp@next to get 4.0. There are going to be migration pains, so we didn’t want to install it by default for a brand new user. Before we make it the default, I’d like to have an official migration guide in place and do a full review and/or rewrite of the docs.

When will it install by default?

I don’t have any timelines because documentation is very hard to get right. SomethingNew71 is working on website improvements that will display our docs so you don’t have to read from the markdown files.

Gulp is a combination of small libraries. Did you write any new ones that the world should know about?

Yeah! I’m really happy with a library that I created a while ago called async-done. It’s really cool because it allows us to handle all sorts of different types of async operations uniformly. This module is what enables you to return promises, streams, or observables, among other things, from gulp tasks and orchestrate whether they should be run in series or parallel. But it doesn’t just apply to gulp; you can use it with things like the async library on npm. There are already a handful of non-gulp projects using async-done and I hope others adopt it.

If I don’t have the time or technical prowess to help out with code or docs, how else can I contribute to make sure gulp thrives?

We have an Open Collective where anyone can donate! We have things like a t-shirt tier and even display the top 10 donors on our website. So there are benefits for you and/or your employer to donate.

Thanks Blaine!

A little postmortem​

Last week we made gulp v4.0.0-alpha.3 available on GitHub and people are excited! We expected it to be breaking, but we didn’t realize the far reaching impact of the changes. This is due to 6,752 modules that depend on gulp-util; many of which utilize an extremely outdated version of Vinyl.

Help us fix it using the steps below.

Why deprecation now?​

We’ve been planning to deprecate gulp-util since 2014 because it’s just grab-bag of modules. Why would you want to download the beeper module if you’re only using gulp-util for logging? It drastically increases the download size of plugins and gulp itself. We had hoped people would transition to smaller modules, but it seems everyone continued with the status quo.

We planned to deprecate using an easier transition path, but last week’s changes proved it’s a bigger problem than we anticipated. The outdated Vinyl dependency is incompatible, but still used by many plugins. However, v2 of Vinyl won’t ship with gulp-util because we want plugin authors to transition to individual modules.

This has lead us to flag the module on npm with a warning — not the elegant transition we had hoped. You’ll be notified of the deprecation when gulp-util is installed by one of your plugins, but you won’t know which plugin is causing the warning until you follow the fix below.

It’s possible that a plugin using gulp-util isn’t broken if it’s not using the gutil.File API. While not as urgent, the plugin author should still transition away from gulp-util.

Help us fix the ecosystem​

Using these steps, you can help plugin authors migrate away from gulp-util.

1. Run npm ls gulp-util to get the list of plugins dependent on it.
2. For each dependent plugin, run npm issues {PLUGIN NAME} which will open their issue tracker.
3. Open an issue or pull request to remove gulp-util using the following API replacements:

• gutil.File => https://www.npmjs.com/package/vinyl
• gutil.replaceExtension => The .extname property on Vinyl objects or https://www.npmjs.com/package/replace-ext
• gutil.colors => https://www.npmjs.com/package/ansi-colors
• gutil.date => https://www.npmjs.com/package/date-format
• gutil.log => https://www.npmjs.com/package/fancy-log
• gutil.template => https://www.npmjs.com/package/lodash.template
• gutil.env => https://www.npmjs.com/package/minimist
• gutil.beep => https://www.npmjs.com/package/beeper
• gutil.noop => https://www.npmjs.com/package/through2
• gutil.isStream => Use the .isStream() method on Vinyl objects
• gutil.isBuffer => Use the .isBuffer() method on Vinyl objects
• gutil.isNull => Use the .isNull() method on Vinyl objects
• gutil.linefeed => Use the string '\n' in your code
• gutil.combine => https://www.npmjs.com/package/multipipe
• gutil.buffer => https://www.npmjs.com/package/list-stream
• gutil.PluginError => https://www.npmjs.com/package/plugin-error

This is part of our Gulp Sips series: bringing you easily-digestible bits of information on our advanced or unknown features.

Two Types of Streams​

In Node, streams can operate in one of two modes; for the purposes of gulp, the two modes are incompatible.

• Buffer mode: Operates exclusively on buffered data. If we stream a file in this mode, it would only contain the content of the file. We’d even lose the filename.
• Object mode: Accepts any object flowing through it. A file streamed in object mode can contain all sorts of metadata (filename, stats, etc.), along with the content.

Benefits of Object Mode​

In buffer mode, using something like fs.createReadStream('index.js'), you’d have to operate on a singular file.

Instead, we utilize streams in object mode so we can operate on multiple files using a single stream. For example, gulp.src('*.js') reads all files ending in .js and emits each as an object on the stream.

For every file, we track a lot of metadata along with the content. This allows plugins to operate upon any of that metadata before we write it out to disk.

There are ways to convert between types, but they require external modules, like vinyl-source-stream.

Utilizing Gulp Plugins​

Every gulp plugin should be a Transform stream in object mode. These streams understand and operate on gulp’s data, while streams operating in buffer mode would throw an error.

Generally, a gulp stream begins with gulp.src() and terminates with gulp.dest(). For best results, streams between should be a gulp plugin or a stream that understands Vinyl objects.

This is part of our Gulp Sips series: bringing you easily-digestible bits of information on our advanced or unknown features.

Descriptions and Flags​

Our users frequently requested the ability to add descriptions to their gulp tasks. The suggested solution was to add a method like gulp.description(); however, we didn’t want to expand our API surface and wanted to support documenting custom flags.

We searched for a more elegant solution and found the most flexible option was attaching static properties to task functions containing the custom metadata. So, you can leverage existing language features instead of custom APIs. It also allows us to support other types of metadata in the future.

Supported Properties​

• .description: Assign a string description to your task function.

function clean() { … }
clean.description = 'Cleans up generated files.';

• .flags: Assign an object of flags to your task function. Each key should be a flag and its value should be the description of that flag.

function build() { … }
build.flags = {
  '--prod': 'Builds in production mode.'
};

Put It All Together​

Before you get started, ensure that you are using gulp-cli as described in this previous Sip.

You’ll want your gulpfile to look similar to this:

var gulp = require('gulp');
function build() { … }
build.description = 'Build entire project.';
build.flags = {
  '—-prod': 'Builds in production mode (minification, etc).'
};
//If you are using gulp 3.x:
gulp.task('build', build);
//Or if you’ve updated to gulp 4.x
gulp.task(build);

Now run gulp --tasks to see your descriptions and flags. It should look somewhat like the screenshot above the title!

This is part of our Gulp Sips series: bringing you easily-digestible bits of information on our advanced or unknown features.

A Standalone CLI​

Traditionally, you’ve run your tasks using the gulp command installed by the main gulp package on npm. However, we’ve moved away from coupling the CLI and library together. The CLI now lives in the gulp-cli package.

But why?​

This was set into motion because we needed to support versions 3 & 4 (upcoming), even though the two were vastly different. An added benefit is a reduction in the size of global installation.

We were also able to version separately from the main package, allowing for features and bug fixes without impacting your workflow. Many of those features will be topics of upcoming Sips, including adding custom metadata to tasks and utilizing configuration files.

Use it now!​

If you’ve globally installed gulp before, you’ll want to remove the old version. To check your version, run:

gulp -v

If you don’t see CLI Version 1.x (as shown above), remove your old installation by running:

npm rm --global gulp

Now, you can install the standalone CLI using:

npm install --global gulp-cli

Run gulp -v again. Everything should match the screenshot above.