Tools To Notify You When Dependencies Update

Any given website has, approximately, a whole bunch of dependencies. Take CodePen. The site is Ruby on Rails. Both Ruby and Rails are actively developed, versioned dependencies. There are a good 30+ gems in the project that help us do different internal things (e.g. process Sass into CSS) and user-facing things (e.g. process user-generated Markdown). Those gems are versioned dependencies. Not to mention front-end libraries we use. Not to mention Not to mention server-level software. Not to mention Node stuff.

It’s a good idea to keep those things up-to-date (new features! security updates!), but also to do it on your own terms so you know what’s changing and can test accordingly. But how do you know a new version of a dependency has been released? Let us count the ways.

Manually check

You can always just, you know, look. Perhaps not super efficient, but it does the trick.

In the case of gems, you can run gem outdated (or bundle outdated) to see a list of all the gems you have that are behind. gem update will update all of them (probably a bit heavy-handed for most apps), so gem update gemname is useful for hitting just the ones you want to update.

In the case of node, there is also a npm outdated command to see what is old. Then there is a trick where you can change the dependency version in the `package.json` file to “*” then running npm update --save. Probably even better, there is a package, npm-check-updates, specifically for helping with this process.

If you’re using Bower, there is bower-list which can help you see which of your dependencies are outdated, but it lists everything, not just the outdated ones. Looks like they are discussing improving that.

Sometimes the software you are using has a system for updates already. For instance in WordPress, they are very clear in the admin area when plugins, themes, or WordPress itself needs an update and allows you to do that right from the admin area itself. But WordPress won’t tell you if the version of PHP your server runs is out of date, or if your OpenSSL software is old, or if the grid framework you used to build your theme has a new version out.

Subscribe to releases via RSS

GitHub repos have a releases section (example). You can get a feed of those releases at a URL like this:

https://github.com/rails/rails/releases.atom

or

https://github.com/rails/rails/tags.atom

Subscribe to that in your feed reader of choice for notifications.

A feed reader isn’t the only way to consume RSS though. You could, for example, get fancy and use IFTTT to send you an iOS notification or an email when a new RSS entry is published (meaning a new version of a dependency has been published).

Sometimes it makes sense to have one RSS feed for all this too. You can use Yahoo Pipes to combine RSS feeds pretty easily.

Screen scrape

If the dependency you use isn’t on GitHub, or otherwise has no feed or practical way to watch it, you could rely on scraping the screen of wherever URL it lives at on the web to check for changes. The Chrome extension Page Monitor could help with that.

Use a Service

Sibbell is one that came recommended when I was asking around about this. I can vouch for it. We’ve been using it at CodePen and it’s been working great.

You don’t have to change anything, just star or watch the projects that you use on GitHub.
When a new release is published, Sibbell will let you know.

VersionEye is another one that works a slightly different way:

VersionEye shows you all supported project files in all branches for all of your repositories. After parsing your project file you can immediately see which dependencies are outdated.

VersionEye currently supports these 10 package managers: Composer, Bundler, PIP, NPM, Bower, Leiningen, CocoaPods, Maven, SBT and Gradle.

Along those same lines, there is also Gemnasium:

Gemnasium parses your project’s dependencies and notifies you when new versions are released or they need to be updated.

and Libraries.io:

You can … be notified of new releases to keep your applications secure and up to date.

Fair Warning

Always be careful granting access to your GitHub account to third parties. If you have private repos, they are probably private for a good reason. Any security breach at those third parties and access to those repos could end up in the wrong hands. In the case of Sibbell, it’s easy enough to create a GitHub account just for it and star the stuff you want to watch through that. It’s harder with the services that watch your dependency files in your real repos.

I’m not saying don’t use these things, I’m saying use good judgement and team communication about stuff like this.

What do you do?

Have a homegrown method? Use one of these? Do nothing?