‘onelineperfile': a custom formatter for ESLint that, unsurprisingly, displays one line per file

If you use ESLint you probably already know that it comes with six formatters (a.k.a. reporters) that allow you to change the way that messages output by ESLint are reported.
Briefly, the six styles are:

Stylish (the default formatter)













Each of these are good for what they do but none of them are exactly what I need, which is output with:

  • One line for each file processed
  • Each line to indicate the status of the linting; success, error or warning
  • Each line to indicate the number of errors / warnings, if any
  • No error details to be displayed, I can check and fix that in the editor if needed
  • A summary line showing the total number of files processed, the number which passed linting and the number with warnings or errors

The reason for these requirements is to allow the output to be used in an audit trail, for example as the result of running a Git pre-receive hook; I should easily be able to check that a particular file was linted and it’s status.

Luckily, ESLint is very extensible so I created a new formatter — onelineperfile — which meets all of my criteria.

Here’s sample output:


The easiest way to add it to your project is using NPM:

npm install --save-dev eslint-onelineperfile

You can then run it directly from the command line:

eslint --format node_modules/eslint-onelineperfile/onelineperfile.js <span class="keyword operator shell">*</span>.js

If you prefer to automate ESLint you can do so using Grunt ESLint:

    eslint: {
      options: {
        format: require('eslint-onelineperfile')
      target: ['*.js']

grunt.registerTask('default', ['eslint']);


The work #3

Some mornings, in a perfect world, you might wake up, have a coffee, finish meditation, and say ‘Okay, today I’m going into the shop to work on a lamp.’ This idea comes to you, you can see it, but to accomplish it you need what I call a ‘setup.’ For example, you may need a working shop or a working painting studio. You may need a working music studio. Or a computer room where you can write something. It’s crucial to have a setup, so that, at any given moment, when you get an idea, you have the place and the tools to make it happen.
If you don’t have a setup, there are many times when you get the inspiration, the idea, but you have no tools, no place to put it together. And the idea just sits there and festers. Over time it will go away. You didn’t fulfill it – and that’s just a heartache.

— David Lynch, “Catching the Big Fish”


Developer Essentials: Velcro Ties and Grid-It

Like most developers I feel compelled to carry around a cornucopia of cables and computer accessories because, well, “you never know”:

  • Phone cable, check.
  • iPad cable, check.
  • USB cable, check.
  • Mini-USB cable, check.
  • Micro-USB cable, check.
  • Earbuds, check.
  • Headphones, check.
  • HDMI adaptor, check.
  • Network cable, check.
  • Miscellaneous adaptors, check.

And so on. And on.
Until recently, I’d throw them all into the bottom of my rucksack and go. No hassle, until it came to finding the one I actually needed. If it was there at all — if I’d remembered to pack it — I’d then struggle to untangle it from the rat king that skulked in the bottom of that bag.

Thankfully the solution to this disastrous disarray was both simple and inexpensive.

Step 1: Velcro Ties


If you do nothing else to get your cables organised, buy a pack of Velcro Ties. Sold in various widths, they’re actually a single roll of Velcro, the hook and loop fastener, that you cut to length.

Loosely fold your cable and hold it in place by wrapping your Velcro round it (it will stick to itself). Result? No more tangles (TM, probably). For most laptop type cables — USB, etc — I’ve found the 10mm (1/2 inch) width works best. Each cable usually needs a strip about 5cm (2 inches) long. With 5m (15 feet) on a roll, you can sort out a lot of mess.

Step 2: Grid-It

Once your cables are permanently detangled , you’re ready to take it to the next level; the Grid-It.


Grid-It is one of those ideas that just seems so obvious when you use it for the first time. Comprised of a lightweight, firm base (optionally with a small pocket on the back) covered in rubberized elastic bands, it can easily accommodate dozens of cables or small accessories of varying shapes and sizes. Each is held firmly in place and won’t slip out in your bag or backpack.

They come in various sizes but I’ve found the medium (approximately the size of a sheet of A4 / Letter paper) to be more than sufficient for my everyday needs. Now, all I need do is slip my Grid-It into my rucksack and slip it out when I reach my destination.

Just two simple and inexpensive products and you’re organised. Slip on your headphones, sign in to calm.com, and relax in the knowledge that your essential cables are exactly where you need them to be and ready to use just when you need them.


Ensuring editing consistency with .editorconfig

Today I updated my recently created GitHub repo configs to include my .editorconfig file. EditorConfig is one of those incredibly simple ideas that I initially hesitated to install (“is that all it does?”) but now find invaluable. By defining a few properties in a file that you store in your repo, usually in the root, you can go some way to ensuring that everyone that works on your source uses the same basic whitespace settings; indent style, indent size, line terminator, and so on.

Nowadays, many (most?) editors allow for settings at both the user and project level, but often a project repo doesn’t include a settings file for the project or, if it does, it’s for an editor that you don’t use. If you work on multiple projects with differing conventions or even just in a team where everyone uses their own favourite editor, EditorConfig can ensure consistency of layout and less time wasted in reformatting.

EditorConfig consists of two parts; a simple configuration file, .editorconfig, and an editor/IDE plugin. Once you have selected and installed the plugin for your preferred editor (at the time of writing there were over twenty available) you can set your preferences and you’re ready to go. As it’s a simple text file it can be checked into your repo to ensure that everyone working on your project shares the same settings.

The config file allows eight properties to be set with seven of them allowing you to control the appearance of your code.


EditorConfig is one of those things, like Markdown formatted ReadMe’s, that has become ubiquitous in open source projects. Even a cursory browse through GitHub or BitBucket will reveal that many projects make use of it.

My own .editorconfig can be found in my configs repo, a small collection of my most-used config files on GitHub.



The work #2

Of the hundreds upon hundreds of programmers we’ve worked or spoken with in the past year, I can’t think of a single time when the existence or absence of a degree made any difference. Anecdotally, we’ve seen little correlation between being a good programmer and having a degree in computer science (yes, even when it comes to understanding stuff like the growth of functions or tail-call optimization). There does, however, seem to be a strong correlation between writing lots of code, loving programming, and being awesome.

— Nick Bergson-Shilcock


Moving a tag on a Git branch to a different commit

Today I slipped up when assigning a release tag to a Git repo. After committing my changes and pushing them to GitHub I tagged the HEAD as v1.0.0 and pushed the tags to the remote. Almost immediately I realised that I had forgotten to make a change that I really wanted to be included in that release. Now, the changes had already been pushed to the remote (GitHub in this case) so the sensible and proper thing to do would be to commit my fix and tag it as v1.0.1 but, as this is currently a private repo which only I have access to, I decided to move the tag.
It’s been a while since I’ve done that so it took me a few attempts to remember exactly the steps involved so I thought I’d document them here “just in case”.

If all you’re looking for is the commands, here they are (in these examples I’m assuming the tag to be moved is ‘v1.0.0′). A more detailed explanation follows.

$ git tag -d v1.0.0

$ git push origin :refs/tags/v1.0.0

$ git tag v1.0.0

$ git push origin master --tags

How it works

Firstly, let’s have a look at the state of the repo before running any of these commands

$ git log

* 276ceee (HEAD, master) Fixed spelling.
* 204f97c (tag: v1.0.0, origin/master) Initial commit.

As expected, the tag v1.0.0 is on the initial commit rather than the HEAD, which is where we want it to be.
[Note that I’ve abbreviated the output for clarity].

A quick check of the repo in GitHub confirms that the tag has already been pushed, and is associated with commit 204f97c


The first thing we want to do is delete the v1.0.0 tag from the local repo using git tag -d:

$ git tag -d v1.0.0

Deleted tag 'v1.0.0' (was 204f97c)

$ git log

* 276ceee (HEAD, master) Fixed spelling.
* 204f97c (origin/master) Initial commit.

Then remove it from the remote repo (GitHub):

$ git push origin :refs/tags/v1.0.0

To https://github.com/davidwaterston/test.git
- [deleted] v1.0.0

Then we can assign the tag to the new HEAD:

$ git tag v1.0.0
$ git lg
* 276ceee (HEAD, tag: v1.0.0, master) Fixed spelling.
* 204f97c (origin/master) Initial commit.

and push it to the remote:

$ git push origin master --tags

Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 288 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To https://github.com/davidwaterston/test.git
204f97c..276ceee master -&amp;gt; master
* [new tag] v1.0.0 -&amp;gt; v1.0.0

Another quick look at GitHub and we can see that the tag is still there but has been moved to the new commit, 276ceee:


Mission accomplished.