Key Location. Prior to this I was lucky to catch the tail end of a great period in "telecoms" via a startup that IPO'd and was later acquired.For the past few years I've been building a rental information site in Singapore called
Renovate provides a way to automate the updating of
package.json dependencies within a project's workflow via the use of branches, CI testing and pull requests.
Renovate scans each repository for all
package.json files, and checks with the npm registry if any existing dependencies have newer versions available.
Once renovate has a list of upgrade candidates, it creates branches in the repository for testing each upgrade individually, and can also open pull requests - either immediately after the branch is created or after tests have completed.
By default it also separates major releases into their own branches / pull requests. For example, you might be testing a patch update to webpack 2.x while also seeing if / where webpack 3.0 breaks in your build.
It's somewhat configurable and tries not to be too opinionated, so almost every step above could be accompanied with a "...unless you configure it to..." disclaimer.
The main alternative that many are familiar with is Greenkeeper, a commercial service for a similar purpose that has deservedly become fairly well known and used.
Philosophically, renovate differs by being an "open source first" project where the primary aim is to allow people to run it themselves easily (e.g. with
npm i -g renovate). Existing commercial services had / have the approach of "telling you when updates to your dependencies break your software".
I prefer a default approach of locking down exactly what dependencies are present and not upgrading unless they pass tests. For instance, these other solutions pin dependency versions if something breaks, whereas I prefer to pin the versions by default, including using yarn or npm lock files.
Technically, renovate has a few nice features which I believe are currently unique:
package.jsonfiles in a monorepo
package-lock.jsonfiles with any
package.jsonupdates, if they already existed
devDependencies-only, etc) once they pass tests, to reduce human work
yarn.lockupdated even if
package.jsonversions haven't changed
repository. So if there's a crash or resumption, there is no need to rebuild anything or worry about duplicates.
Like many others, I had a personal itch to scratch.
I previously had needed to disable automatic dependency updates on my main website project because none of the existing services supported monorepo repository structures. After subsequently wasting half a day troubleshooting a browser issue which turned out to be caused and already fixed by a dependency I had missed updating, I decided I'd hack together a script to manage monorepo
package.json updates from the CLI.
Once I found out that it could be done relatively elegantly using the GitHub REST API (not requiring any
git cloning), I decided to make it less hacky and open source it for others in a similar situation. So primarily this was driven by a technical need rather than any particular desire to build an open source version of something.
I've recently added renovate as a free GitHub app. Again, the code for this is completely open source and I was happy to find out how simple it was to add the integration. As simple as running the script is, I think a lot of people prefer not to maintain yet another server or cron job in their routines so this is another option.
Functionality-wise, I'm looking into:
One related trend I would like to see is the end to "snippets" for embedding closed-source third party libraries into websites. Developers need to seize back more control in terms of bundling, loading timing and priority, etc. The whole "this won't slow down your website" disclaimer that most use is obviously a load of bunk.
There are few vendors supporting this approach so far (i.e. open sourcing their client JS code as an alternative to loading via snippet) and market forces would suggest this is because customer developers aren't asking loud enough.
You would be surprised at how much experience and exposure you can get by contributing small patches and fixes to existing open source libraries.
Once you start noticing certain prolific open source authors, it's like the yellow car phenomenom and you start noticing the same people everywhere. Gleb Bahmutov is one of those for me, although I'm not sure if he could easily decide which of his libraries to make a focus of an interview.
Naturally I need to thank the hundreds of authors and maintainers of software I use every day, including as a part of renovate. And thanks for having me on the blog!
Thanks for the interview Rhys! renovate certainly looks like a solid solution to an important problem.
Learn more about the project at GitHub.