‘onelineperfile’: a custom formatter for ESLint

‘onelineperfile’ is a new custom formatter for ESLint that, unsurprisingly, displays one line per file. Linting details are displayed whether the file passed linting or not.

 
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)

eslint_stylish

Checkstyle

eslint-checkstyle

Compact

eslint_compact

JSLint-XML

eslint-jslint-xml

JUnit

eslint-junit

Tap

eslint-tap

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:

eslint_onelineperfile

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:

  grunt.initConfig({
    eslint: {
      options: {
        format: require('eslint-onelineperfile')
      },
      target: ['*.js']
    }
});

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



More:

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

Tags_1

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:

Tags_2

Mission accomplished.

A new GitHub repo for config files

 
Earlier today I created a new public GitHub repo, called configs, appropriately enough. Simply put, this is going to be somewhere for me to keep my development configuration files so that they are always and easily accessible. Should anyone else find them of use then that would be a bonus.

The first config added to this new repo, .eslintrc, is for ESLint, the linting tool for Javascript and JSX that helps detect errors and highlights confusing constructs and violations of stylistic conventions. Having tried both JSLint and JSHint in the past I settled on ESLint as, compared to those alternatives, I find it to be more comprehensive in its checks, better documented and very easily extended.

I have a number of other config files I intend to add to the new repo but I’m taking the opportunity to give them the once over, refresh their contents and bring them up-to-date so updates will be spread over the next week or so.


More:

Why your jsFiddle no longer works (and how to fix it)

 
If you’re unfamiliar with jsFiddle I recommend you check it out – it’s a great, free playground and an essential tool for web developers. So essential that, over the last few years, it has become almost mandatory for Javascript developers to create a jsFiddle to collaborate on problems with remote colleagues, to offer a library with working, interactive examples, to test proof-of-concepts or to troubleshoot errant code. I’ve lost count of the number of requests for help on Stack Overflow whose first reply is “jsFiddle or it didn’t happen”.

Combining jsFiddle’s interactivity with GitHub’s hosting and version control can greatly increase uptake of your public project. By linking your jsFiddle to GitHub’s raw output you can offer a no cost, no download, no fuss intro to your code.  Instead of asking fellow developers to download and set up your GitHub hosted library you can provide working code examples that instantly show how your code should be used and if it does what they expect it to in they way they expect it to do it. Or rather, that used to be the case. Recent browser changes, particularly to Google Chrome, mean than many existing jsFiddles no longer work. There’s no obvious error but no output appears in the Result.

Click to embiggen

The problem

The problem is simple enough – the external Javascript libraries we are loading from GitHub are no longer being executed. To see why, we need to take a step back. Let’s assume we have a library in GitHub that we want to use in jsFiddle.  To do so, we add the URL of the raw GitHub source in the External Resources section of jsFiddle. This has been common practice for years and used by pretty much everyone because it was easy, convenient and, best of all, it worked.

Adding an external resource to a jsFiddle
Adding an external resource to a jsFiddle. Here, the jlist-min.js library is being loaded directly from raw.github.com.

 

Unfortunately, it worked despite the fact that it shouldn’t have. Files served from raw.github.com are served with a content-type of text/plain. This didn’t used to matter but browsers such as Google Chrome have tightened up security and will now only execute Javascript code that has a content-type of application/javascript . If we look at the console in Chrome Dev Tools while in a jsFiddle that links to raw.github.com we can see the problem:

The error that appears in the Google Chrome console when we link to raw.github.com.
The error that appears in the Google Chrome console when we link to raw.github.com.

What was once acceptable (and very common) practice no longer works.

The solution

Luckily the solution is both simple and less wordy than the problem.
There is a 3rd-party service which will proxy the file you need from raw.github.com and change the content-type before your browser receives it.
To make use of this service, all you need do is remove the full stop (period) from between raw and github in the offending url.
That is

http://raw.github.com/rest_of_the_path

becomes

http://rawgithub.com/rest_of_the_path

 

and your jsFiddle is working again.

 

More:

Note to self: MultiMarkdown style within-document links are not supported in GitHub markdown

MultiMarkdown (MMD) lets us very simply add within-document links (also known as cross-links or cross-references).

Where a heading is defined in a page, like so:

### The Heading

all that we need to do to link to that heading from elsewhere in the same page is to include:

[The Heading][]

This makes it very easy and very quick to, for example, add a table of contents to an existing document – there’s also no need to add extra markup to the linked to heading (in this case) which simplifies and streamlines our document.

This syntax is available in most, if not all, editors that support MultiMarkdown, including my favourite Byword. The important phrase here is “that support MultiMarkdown” – this is not a feature of regular Markdown. Unfortunately, the Markdown supported by GitHub, GitHub Flavored Markdown (GFM), is a variation of regular MarkDown not MMD so, to include within-document links we have to revert to an ugly kludge. Firstly we have to precede the heading we want to link to with a HTML anchor tag:

<a name="headinglink">
### The Heading

and then link to it:

[Click this text to return to the heading](#headinglink)

This works because Markdown allows HTML to be embedded within a Markdown document. As MultiMarkdown is a superset of Markdown, it also supports this syntax as well as the newer style so this should be an acceptable, if ugly, solution in all cases. Note also that, unlike regular HTML, the heading being linked to must be on a separate line from the anchor tag. If you place them on the same line GitHub won’t render the heading properly.

Thankfully, GitHub makes it very easy for us to write and test our Markdown before committing it by providing three very useful resources:

  • Pressing the ‘m’ key while on GitHub.com pops up a Markdown cheat sheet showing the supported syntax
  • GitHub Flavored Markdown describes in more detail the options supported by GitHub and the differences between them and regular Markdown
  • The GFM Live Preview is a web page that allows us to enter some Markdown and instantly see how GitHub will interpret it.
More:


jList: Performance improvements when removing duplicates

Version 1.2.0 of jList brings performance improvements to the two most recently added functions listRemoveDuplicates and listRemoveDuplicatesNoCase. These now run about 30% faster than before though you are unlikely to notice the gains unless you are working with very large lists (100,000+ elements) or running it many times consecutively.

I intend to post later this week about efficiently removing duplicates from Javascript arrays so I shall cover what changes I made in more detail as part of that post.

More:

jList: Two new functions to dedupe lists in Javascript

Earlier today I released version 1.1.0 of the jList Javascript library. This release adds two new functions, bringing the total to 15.

The new functions are:

  • listRemoveDuplicates
  • listRemoveDuplicatesNoCase

As you might guess from the names these are intended to remove duplicate elements from lists.

A simple code snippet illustrates the difference between the two:

mylist = 'cat,dog,monkey,DOG,Dog,cat';

response = jList.listRemoveDuplicates(mylist);
console.log (response);

response = jList.listRemoveDuplicatesNoCase(mylist);
console.log (response);

In line 3 we perform case-sensitive matching when looking for duplicates. As a result, we don’t consider ‘dog’ to be the equivalent of ‘DOG’ or ‘Dog’ so the result displayed in line 4 will be ‘cat,dog,monkey,DOG,Dog’ – only the duplicate ‘cat’ has been removed.

In line 4 we perform case-insensitive matching when looking for duplicates. As a result, the output from line 7 will be ‘cat,dog,monkey’ as ‘dog’, ‘DOG’ and ‘dog’ are all considered equivalent in this case.

Notice also that in both functions the order of the list elements is unchanged. This illustrates that it’s the second and subsequent occurrences of an element that are considered to be the duplicates and removed, the first occurrence remains in its original place within the list.

The new version of jList, including updated documentation, is available for download from GitHub.

More: