Disable ESLint for a file

I love ESLint. I really do. But sometimes it feels like an abusive relationship.

Developer: Look, I just need this built to complete so I can get this task done and go on vacation.
ESLint: No. Here’s a bunch of things you need to fix.
Developer: What the hell! 10 errors in SomeJSFile.js? I didn’t even touch that file! How did that code get in the repo?
ESLint: Not my problem, pal. Fix it.

Sometimes you just need to tell ESLint to look the other way so you can get the job done. And for that, there’s this:

/* eslint-disable */

Put this line of code at the top of your file, and ESLint will look the other way.

Just make sure you enter a ticket to fix that garbage code at a later date.


Take a big Gulp

Over the last few years, many of the projects I’ve worked on have been complex enough to warrant using a task runner to handle the process of compilation (in the case of Coffeescript, LESS and SASS files), concatenation and minification. Grunt emerged as the early favorite in this category because it was relatively easy to use and had a strong community backing.

But, as it always is with Javascript frameworks and toolsets, times change.

Now, Gulp.js has emerged as a competitor to Grunt. It’s designed for the same tasks as Grunt, but sports a few benefits.

The first that appealed to me was that with Gulp, you are writing your tasks in Javascript. Not JSON, but Javascript. This is a matter of preference I suppose, but I found writing my gulpfile out more descriptive than the JSON configuration files you use with Grunt.

Second, I like how in Gulp you can pipe, or chain your tasks together. As you are writing your tasks out, this mimics the workflow you’d like your files to be processed under, and it just makes sense from a coding perspective.

 gulp.task('galleryJs', function() {
 // .pipe(uglify())
 .pipe(rename({suffix: '.min'}))

In the example above, the task ‘galleryJs’ takes the array of files with this name and passes it to the tasks concat (which concatenates all the files in to one), then that output is piped to uglify (minification), then the file is renamed (with the suffix ‘.min’ appended), then the header task is run (which prepends a timestamp to the file so you can easily see when it was generated – very helpful when trying to see if a minified file is updated or cached), and file it’s moved to the ‘assets/js’ directory with gulp.dest.

Third, and my favorite, is that with the –save-dev argument, Gulp will save the packages used in your gulpfile to a node_modules directory, meaning (assuming you are checking this in to Git) that the next person who checks out your branch won’t have to manually download these packages for Gulp to work. I’m not sure if this was possible with Grunt, but it seemed like every project I ever used Grunt on required the user first to make sure they had all the packages Grunt was referencing in the gruntfile.

Speed between the two task runners seems about the same. I find that I can write tasks quicker in Gulp, so overall the process of using Gulp seems quicker, at least for me.

The one area where Grunt still reigns supreme is in the sheer number of packages available for it (compared to Gulp). Gulp is gaining a lot of traction, but Grunt still has more packages available forĀ it, for now.