gulp is simply vinyl, vinyl-fs, orchestrator, a CLI, and a set of guidelines to help people make good plugins. Even with a tiny feature set, it has completely disrupted the build tool ecosystem and kicked off a new wave of awesome projects that are revolutionizing your workflow.
Let’s start from the bottom and work our way up while explaining some of the pieces behind gulp and where they’re headed.
Streams are a way of piecing small transform operations together into a pipeline. You drop things in the top, they fall through all of the transforms, and you end up with things coming out the bottom. Streams are a flexible system that solve the problem of file transformations very well.
For more information about streams check out the Stream Handbook by substack.
Vinyl is a very simple metadata object that describes a file. When you think of a file, two attributes come to mind: path and contents. These are the main attributes on a Vinyl object. A file does not necessarily represent something on your computer’s file system. You have files on S3, FTP, Dropbox, Box, CloudThingly.io and other services. Vinyl can be used to describe files from all of these sources.
While Vinyl provides a clean way to describe a file, we now need a way to access these files. Each file source needs what I call a “Vinyl adapter”. A Vinyl adapter simply exposes a .src(globs), a .dest(folder), and a .watch(globs, fn). The src stream produces file objects, and the dest stream consumes file objects.
It seems like people really understood the concept of a “gulp plugin” (a transform stream) but the idea of vinyl adapters never really clicked with many. I’m not sure how to make this catch on besides making some more of these myself so they can be used for reference. The idea of being able to use gulp as a deployment tool via vinyl adapters is intriguing.
If you use gulp, you have used the vinyl-fs module. It is the adapter for your local file system.
This does not exist yet, but gulp-s3 does. It doesn’t provide all of the functionality required but it should provide a decent stopgap.
As of this article, the current task system is Orchestrator 0.3. Orchestrator provides an easy way to define tasks, task dependencies, and run tasks with maximum concurrency while respecting the dependency tree. While Orchestator has served us well, the syntax has confused users due to the complexity of dependency management. Orchestrator is undergoing a huge overhaul to align with the ideals that gulp was built upon: small implementation, low complexity, and composable functional-leaning APIs.
To give a quick summary of the changes coming in gulp 4:
- You specify your task ordering, so parallel/series and any combination of those is possible. Your imagination is the limit, the technical barriers will be lifted.
- The API will be fluent and looks crazy good
- The code base will be simpler
Huge thanks Blaine Bublitz for taking the initiative to work on this.
I’ll be completely honest with you: error management in gulp sucks currently. I simply did not anticipate some use cases and a few things fell through the cracks. Within gulp, we have two types of errors you can encounter:
A task fails
When a task fails the internals of watch get messed up and you may encounter a process exit depending on how the task was started. This is bad and should never have happened, but it did and it will be fixed with the new task system.
A piece of a pipeline fails
The standard Stream behavior is to simply stop working when an error happens. For tasks like linters, you can see how this is an issue. I want to see all of the linting issues, not only the ones from the first file that passed through. To get technical, this is due to the unpipe event. Essentially what happens is when a stream encounters an error, it emits this event which tells streams to stop writing data to it. There are some hacky workarounds like gulp-plumber that can be used as a stopgap, but I’m pleased to say that I have decided to bring this functionality into gulp core.
These issues are my highest priority for the next release.
From an outsider’s perspective, it seems insane that people would be gripped with this battle about file transformation tools. While it seems uninteresting to the outside world, it’s absolutely exhilarating to be a part of such a passionate group of people. I’m very proud of the way the community has managed to latch onto this tool and catapult it into being an instrumental piece in people’s daily lives.
To follow progress on gulp 4 you can check out the milestone on github.