Why you should version your Node dependencies using tilde

I’m going to assume you’re already familiar with SemVer and the NPM tilde extension. If not, get your eye holes around those links, particularly the second one.

Ever since I’ve been working on David I’ve seen a lot of version numbers for node projects. I’ve also authored a few npm packages and node projects myself. I find it hard understand why you wouldn’t use tilde to specify the versions of your dependencies. For example:


This is shorthand for >= 1.0.2 < 1.1.0. It is saying: If the major or minor version increases then I need to retest my code to check it works on the new version, so don’t depend on that. Although, if there are bug fixes, I want them, and whilst I understand that a bugfix release could break my software, it isn’t meant to, so I’m willing to take the gamble.

The idea is that you’re allowing your dependencies to “self update” within a range that is safe to do so. This is really powerful and you should be using it.

I’ve seen a lot of absolute versions for dependencies, which is fine (you know who you are, you have your reasons), but I also see a lot of reckless version ranges: “>= 0.3.14″, “*”, “latest” which are just mad. How can you possibly know your code will still work as your dependencies transition between major and minor version numbers?

David, a dependency management tool for Nodejs projects

I made a thing. I noticed that there wasn’t a way to visualise which of my Nodejs project dependencies were out of date. I saw a library called police which looked pretty awesome, but I wanted to provide a bit more of a service – A quick and easy way for developers to advertise that their project was up to date, in the same way that Travis provides a “badge” that always shows the current build status for your project.

Badges are great, everyone like badges. The Travis badge is an admission by the developers who work on the project that they’re committed to keeping their code base in working order for both consumers of the software and developers alike. Travis proves that their project works by ensuring it can be built successfully and that it passes any unit or integration tests the developers have written. Consumers and developers can see the build status of the project at a glance, without having to clone or checkout the code.

The David badge shows that the project developers are committed to maintaining and improving the project, keeping it up to date, secure, efficient and (hopefully) bug free by keeping abreast of changes in the code the project depends upon.

Of course, an “out of date” David badge can be a indication of a low level of project activity and a hint at the level of support you’re likely to get should you encounter a problem (not much).

Clicking on a David badge will normally take you to the project status page, which lists project dependencies, the version required by the project and the latest version available in the NPM registry. It gives you an idea of the complexity, size and scope of a project and most importantly, it shows developers what dependencies need updating! Here’s some examples

David is written in JavaScript, it uses Nodejs and NPM (of course). It was built from the GRUNTEND base with the Express web application framework.

Check out David here: david-dm.org

VB.NET and project imports

Much to my displeasure, I’ve recently inherited an ASP.NET 1.1 website. After a bit of a wrestle they eventually handed over the source code (Why are .NET developers so precious over their code?). Unfortunately they didn’t hand over the Visual Studio project or solution files as well.

Fair enough, I can easily create a new solution and import all the code…no problem. Except there were problems, 104 of them. If you’ve used Visual Studio before you’re likely to know what that means. It means: a shit load of errors, except I’m only going to show you 104 of them.

The kind of stuff I was getting was:

Type 'Control' is not defined.

…and there were no error messages for missing imports. I scratched my head for ages until I thought of the notion of “automatic imports”. What if, these guys have somehow specified a set of imports that get appended automatically to each file…which I haven’t defined?

Turns out, you friggin can do exactly that. In Visual Studio 2003 it is: Right click on project > properties > project properties > imports.

Who the hell thought of that? Surely it is a completely ludicrous idea! It means that if the code gets separated from the project (which is exactly what happened) it won’t work correctly. Not only that, but how the hell am I supposed to know if MyClassName belongs to com.companyX.package or com.companyY.package???

So I’m just totally guessing at the moment, and I’m down to 18 errors. Man I hope it eventually runs.