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.


NodeJS 4.0

Node 4.0 has been released. This release is significant for a number of reasons, one of which is the merging of the NodeJS and the io.js projects in to one. The new Node (from version 4.0 and onward) will be based on the io.js repo. This should unify the Node project, which had seen some dissent in the ranks over the last year or so as some NodeJS contributors had moved over to the io.js project.

Of note, if you upgrade to v4.0 and run in to issues, you can always (and easily) roll back to prior versions.

For example, when I upgraded to v4.0, I got these errors when trying to run gulp:

    throw new Error(['`libsass` bindings not found in ', binaryPath, '. Try reinstalling `node-sass`?'].join(''));
Error: `libsass` bindings not found in ~/Sites/my-awesome-project/node_modules/gulp-sass/node_modules/node-sass/vendor/darwin-x64-46/binding.node. Try reinstalling `node-sass`?
    at Object.sass.getBinaryPath (~/Sites/my-awesome-project/node_modules/gulp-sass/node_modules/node-sass/lib/extensions.js:148:11)
    at Object.<anonymous> (~/Sites/my-awesome-project/node_modules/gulp-sass/node_modules/node-sass/lib/index.js:16:36)
    at Module._compile (module.js:434:26)
    at Object.Module._extensions..js (module.js:452:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Module.require (module.js:365:17)
    at require (module.js:384:17)
    at Object.<anonymous> (~/Sites/my-awesome-project/node_modules/gulp-sass/index.js:163:21)
    at Module._compile (module.js:434:26)

Attempting to upgrade node-sass and gulp-sass had no effect on fixing it.

So, I had to roll back to v 0.12.7, the last release before the 4.0 merge. Thankfully, once I exhausted every other attempt to fix the issue, rolling back was easy.

In case you didn’t know, you can upgrade/downgrade Node itself thru npm. Here’s how:

sudo npm cache clean -f
sudo npm install -g n
sudo n 0.12.7

“n” is a helper package that allows you to upgrade/downgrade your node instance.



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.