Nate Eagle

Front-End Developer

Gulp Pattern Lint

When Grunt came along, it really changed the way I set up all my projects as a front-end developer. Instead of sometimes having a Compass project or sometimes having a Jekyll project, everything became a Grunt project. Instead of relying on my own workflow for things like JSHint settings and text-editor preferences, I started setting up all those specifications on a project level. Rather than relying on globally installed ruby gems, I began relying on getting everything I needed for a project by typing npm install in a project’s directory. Instead of relying on someone else’s framework, I felt like I was assembling a different toolkit for each project, uniquely suited to the task at hand.

So when Dave sidled up to me at work one day and said, “So, I think we should use Gulp instead of Grunt,” I didn’t react very well. I may have given him a dead-eyed stare and said, “What in the name of Thoth are you talking about?” “It uses streams!” Dave said. “And pipes!” I wasn’t impressed. Streams have to be forded, or you have to caulk the wagon and float across, and usually somebody in the party dies. And pipes are exclusively transportation for Mario brothers. But when my buddy Andrew posted a comparison of one project’s Gruntfile vs. the new Gulpfile he’d made for it, I had to reluctantly concede that the Gulpfile was a lot easier to read.

The strongest reason I saw for trying Gulp was its emphasis on code rather than config. In Grunt, you set up a giant config object, full of tasks and options and file lists and destinations. Any time you have configuration, you have code operating behind the scenes to determine what to do with that configuration. Which means you’ve got to learn about that code’s rules and practices in order to use the configuration properly. And even a year and a half into using Grunt, I still spent a certain amount of time with new projects banging my head against the configuration when it didn’t work the way I expected it to. But Gulp used straight JavaScript to make tasks with a chain of plugins that source files passed through to get to their destination. In Grunt, where I had a config object full of tools (concat, copy, sass, etc) that I told what to do, in Gulp I took a set of files, then passed them through the relevant tools, then put them where I wanted them. Another nice thing about the Gulp approach is that I didn’t have to write the files somewhere after each tool did what it needed to: they could all modify the file as a stream, then pass that stream on. I only wrote the files at the end.

So, fortunately and unfortunately, I abandoned Grunt. I’m pretty sad about that, by the way. Ben Alman created one of the most insanely useful and popular things ever, and suddenly the next thing comes along and Grunt is just over. Every front-end developer I know is switching. The world moves so quickly. Grunt: you will always hold a place in my heart. You changed the way I work.

Enough of this bland storytelling: I created my first gulp plugin, recently, in response to a need we had at work to flag certain bad practices in CMS plugins. Pattern Lint is a linter that works on any kind of file that searches the content for patterns (strings or regular expressions) and flags them, if found, outputting a custom message to your gulp process. We’re using it to warn people not to use http:// links, the wrong form of our CDN url, or vendor prefixes in their CSS file (because the autoprefixer plugin takes care of that).

It mostly works like other linters (I modeled it on gulp-csslint), but I added an excerpting feature to the output reporter that creates an excerpt of the match along with a snippet of the contents before and after to put it into context, with the match highlighted in red. For a while, I was really into doing the JavaScript challenges on coderbyte, which focus a lot on string and array manipulations. It’s mostly stuff I already know how to do, but I found that the speed it gave me when dealing with similar problems that come up at work is really valuable. It’s a bit like doing tsumego to improve your reading ability in go. You work on the stuff you can solve without too much effort to increase the ease and speed with which you can do it in real life.