You could argue that last year was the year of the preprocessors. HAML for HTML, Sass/LESS for CSS and CoffeeScript for JavaScript, to name just a few. If that’s what we’ll remember from 2011, tooling is certainly what I’ll look back on as the “big thing” in 2012.

When Rebecca Murphey wrote her post “A Baseline for Front-End Developers” it included the golden line:

Whatever it is, I think we’re seeing the emphasis shift from valuing trivia to valuing tools.

And I certainly agree wholeheartedly with Rebecca. We’ve seen tools spring up left right and centre to help us develop quicker. Developers are inherently lazy; if we can spend 4 hours writing up a solution to make that boring repetitive task take less time, we will. And that’s good. For a long time developers have been writing small tools to make tasks easier but this year a few have particularly appeared and then spread like wildfire. There’s a lot to cover but in this article I’m going to focus on one area: the command line.

Last year for 12 Devs Kris Noble wrote a post on the Command Line and Vim and since then I’ve seen more and more developers get more comfortable with it. Indeed, in a talk on Better JavaScripting recently I argued that it was no longer an optional extra. If you’re just getting started with the command line or still need some persuading, I hope this article will help. In it I’ll show you a few tools that save me so much time, and are only on the command line.

Be aware: this is not a beginner’s guide to the command line. There’s plenty of them out there. I suggest you read them and revisit once you’re more comfortable with command line basics. I’m also presuming a basic knowledge of JavaScript too. I’ve picked out five tools I use on an almost daily basis to share with you.

Node and npm

A large reason for the sudden flux in tools available and the popularity of the command line can be accredited to Node.js. Node is a JavaScript platform built on top of Google Chrome’s JavaScript engine. It’s capable of a lot, but one thing in particular it facilitates is building command line applications easier than previously. This isn’t a beginner’s Node tutorial, but I’ve written one of those in the past, if you’d like to dive more into Node. A lot of what I’ll mention in this article depends on Node. There’s installation instructions either on the Node.js site, or in the tutorial linked to above. To make sure you’re running Node, load up your command line and run node -v. The current Node version, at the time of writing, is 0.8.16. At the very least, you should be running V0.8+.

npm is a package manager for Node. Once you have this installed, it’s easy to download any of the packages available (at the time of writing, there’s just under 20,000) and use them. Thankfully npm comes when you install Node, so you should already have it. Run npm -v to see.

npm: local vs global install

With npm you can install modules in one of two ways. You can install them locally, which means they are only installed within the directory you run the command from, or you can run them globally, which means they are available everywhere.

Now lets go through some of my favourite command line tools, both generally and with a focus on JavaScript Development. Feel free to recommend your own in the comments.

Package 1: serve

Some of the most useful npm modules are the ones that do one thing, and do one thing well. That’s something that could certainly be used to describe serve. serve is used to run a small local server within the directory in which it’s run. First, lets install it:

npm install -g serve

Running that command with -g makes the installation global. This means we now have the serve executable available to us. You can then serve up directories on a small local server. Navigate into the directory you’d like to serve, and run serve. This will serve those files up to http://localhost:3000. 3000 is serve’s default port number, however it’s possible to change it. If you run serve -p 1234 you’ll get a server run on port 1234. I can’t tell you how many times I’ve used this to quickly run a server to do some development on. Sometimes you can’t just load up the file in the browser; often you need to run code through a server (when making Ajax requests, for example), and when you do serve comes in so handy.

Package 2: Yeoman

Yeoman, in complete contrast to serve, is a much more expansive and fully featured plugin. It’s a community project lead by the likes of Paul Irish, Addy Osmani, and more.

Yeoman is a robust and opinionated set of tools, libraries, and a workflow that can help developers quickly build beautiful, compelling web apps.

Yeoman can do a lot of things, and is designed to be the only main tool you use when working on a JavaScript project. Here’s some of its features:

• automatic compiling of CoffeeScript and Sass/Compass, if your project uses those.
• automatic JSHint code quality checking to make sure your JavaScript is up to scratch (JSHint is covered in more depth later on in this article, keep reading).
• provides a preview server.
• optimises images via OptiPNG and minifies and concatenates CSS/JavaScript through its build script.
• provides scaffolding for new projects including support for unit testing

Yeoman does a lot more too, it is a good idea to spend some time browsing the documentation.

Installing Yeoman isn’t done through npm, but through a shell script:

curl -L get.yeoman.io | bash

Whilst this doesn’t use npm to install Yeoman, the shell script does a lot of extra work, and makes sure your system is ready to run Yeoman. If it detects any issues, it will advise you on how to resolve them before you try to install Yeoman again. Yeoman is so large and complex, it would be impossible to give you a good overview here, as I could write an entire article purely on Yeoman. Instead, I suggest that once you have it installed, you run yeoman init on your command line and go from there. The Yeoman documentation is fantastic and documents clearly how you work with Yeoman. If you work with JS frameworks like Backbone or Ember, Yeoman also has special extra features for working with them. I recommend giving Yeoman a go, it really is a fantastic piece of kit, and essential to the modern JavaScript developer’s toolkit.

Package 3: Grunt

Grunt is another tool for helping with projects.

Grunt is a task-based command line build tool for JavaScript projects

Yeoman is actually built on top of Grunt. Grunt comes with tasks for running unit tests, a build script, code quality checking via JSHint, and more. It’s a smaller feature set than Yeoman. Yeoman is designed for JavaScript heavy applications, perhaps a complex MVC application written in Ember, whilst Grunt is perfect for smaller projects, for example a small JS library or a jQuery plugin.

If you don’t need something quite as extensive as Yeoman, but think you need something a little more smaller and configurable, Grunt is a very good choice. The getting started guide on the wiki is the best place to start.

Package 4: JSHint

Something every JavaScript developer should be doing is linting their code. Linting tools check your code for obvious mistakes and prevent against bad practices, along with spotting easy mistakes, such as forgetting a var keyword or missing a semi-colon where one is needed.

My favourite linting tool is JSHint.

Our goal is to help JavaScript developers write complex programs without worrying about typos and language gotchas.

JSHint is installed through npm (and I suggest you do it globally).

npm install -g jshint

You can then run it against a single JavaScript file:

jshint myfile.js

If you get nothing back, it means the file passed JSHint’s quality check. Else, you’ll get an error that might look like so:

myfile.js: line 11, col 31, Missing semicolon.

Mostly the default JSHint options will be fine, but if there’s certain behaviour you want to change, you can. When JSHint runs, it searches for a .jshintrc file. This means if you want particular options for one project, simply add a .jshintrc file to that project’s folder. JSHint will search up the directory structure for one, so if you want one options file to apply to all your projects, just put it within a folder that encompasses all your projects. Your home folder, for example.

All the options you can provide are documented on the JSHint site. Say I want to set the maxparams option to 3 (this doesn’t allow functions to take more than three parameters for all my projects, my .jshintrc file would look like this (it’s a JSON file):

{
  "maxparams": 3
}

You can also set options inline within the JS file through comments. Adding this comment at the top of a file:

/*jshint maxparams:3 */

Would achieve the same thing.

Package 5: nodefetch

Disclaimer: nodefetch is a project I wrote myself, but I do think it’s useful and I use it so much personally that I thought others might like to know about it.

There are many projects that provide package management for JS libraries. For example, Yeoman lets you run yeoman install jquery to pull down the latest version of jQuery. Jam is also another viable alternative. However, those typically bind you to a specific way of doing things. If you’re already using Yeoman, then use it for package management. Jam uses RequireJS. Sometimes however, you just want a really quick way to download a file, when you’re not already using a tool like Yeoman. That’s why I built nodefetch.

You can install with npm install -g nodefetch. It will place a .nodefetch.json file in your home directory, that links names to downloads. For example, one of the lines in it looks like this:

"backbone" : "http://backbonejs.org/backbone-min.js"

You can then run nodefetch backbone to get the latest Backbone JS minified file downloaded to the directory from which you ran nodefetch. nodefetch doesn’t do anything else, it simply downloads files. I use this very regularly, and I think you might find it useful too.

Conclusion

I could write an article for every day of the 12 days of Christmas, each on five useful JavaScript tools. There’s plenty more that I’d like to have included, but these five are the five I use on a consistent basis. If you’ve got any suggestions, please do leave a comment, or if you have a question please comment and I’ll get back to you.