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.
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:
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.
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.
You can … be notified of new releases to keep your applications secure and up to date.
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?
For WordPress’ers it can be simple, if your workflow fits the following paradigm:
Only enqueue assets that ship with WordPress.
Run the WP nightly on your local to monitor for breakage.
Monitor the changelogs in wp core, noting changes to assets that ship with core.
If you like to sleep well at night, run a service to log JS errors, such as Sentry https://getsentry.com/welcome/ or perhaps a home-baked version. Here’s a proof of concept (not for prod): http://scottfennell.org/2014/10/11/wordpress-plugin-to-log-js-errors-in-a-page/
If you tend to lean on assets that don’t ship with core, that doesn’t quite work. And if you don’t hang out on your local a lot, then that’s a problem as well.
For npm, I prefer David: https://www.npmjs.com/package/david
For me, it’s less about what’s new and more about what should be updated. https://github.com/RetireJS/retire.js helps with that, particularly the grunt plugin.
Please, add into the list mine https://AllMyChanges.com startup. It is a generic release notes tracker where you can add any GitHub project, or any direct URL to a ChangeLog in Markdown, reStructored or HTML, or even to a AppStore/GooglePlay app.
AllMyChanges not only notifies your about new version but also says what is was added, fixed or changed. It is like Feedly but for release notes.
I’d like to throw npm check updates out there. https://www.npmjs.com/package/npm-check-updates
I’ve been using Npm Click recently for checking my NPM dependencies.
Easy, visual way to see what’s out of date. :)
My bad…npm-check-updates is already mentioned in the article.