Now there is a NPM Module for the VersionEye API. The versioneye-update NPM Module was developed by Onwerk, a Software Service Provider from Mannheim (South Germany). They develop web & mobile applications with Node.JS. Like this interactive Jackpot game, built with iPad, XBox Kinect, Raspberry Pi and NodeJS.
The Onwerk engineers like to stay ahead of cutting edge technology. They want to keep their dependencies up-to-date to get bug & security fixes ASAP into their applications. And of course they want to take advantage of new features as soon as possible.
VersionEye has a very good Integration for GitHub and Bitbucket. If your source code is on one of this cloud SCMs, VersionEye can monitor your package.json directly via the GitHub/Bitbucket API and you get notifications about out-dated dependencies automatically.
But the use case for Onwerk is different. They do BIG Software Projects for LARGE customers and because of NDAs und German privacy laws they are not allowed to give out the source code to anybody else. That’s why they are using the VersionEye API to get notified about out-dated dependencies.
And because they wanted to automate the whole process they developed the versioneye-update NPM module, which gets executed on each build on their private Jenkins CI Server. The process looks like this:
The NPM module versioneye-update is running on each build on the Jenkins. The module is sending the current package.json file to the VersionEye API to update an existing VersionEye project. That way VersionEye nows which dependencies are used in the project right now. VersionEye will compare the version numbers from the package.json file with the newest versions in the VersionEye database to find out-dated dependencies. If there is at least 1 out-dated dependency or at least 1 license violation VersionEye will send out an email notification to the project owner and the project collaborators.
That way the whole process is automated. The engineers don’t have to execute wired commands in the console and they are not in risk to forget something. Beside that the source code stays in house. VersionEye never has access to the source code. The only file which has to be shared with VersionEye is the package.json and that doesn’t get stored on the server! After parsing it once the file object becomes a victim of the garbage collection.