🎊 Announcing: Greenkeeper 3
Dear JavaScript Community!
We’ve been hard at work over the past months, improving Greenkeeper in a variety of ways and adding some major features. Aside from doing a lot of internal work on infrastructure, reliability, logging and billing, we’ve expanded Greenkeeper’s capabilities in very visible ways: it now supports monorepos. That means:
- full support for running Greenkeeper on monorepos
- better support for updates from dependencies which are themselves monorepos
Let’s go through the two features in more detail:
🤔 What are Monorepos?
If you’re not familiar with the concept: monorepos are repositories that contain more than one package.json file. Instead of keeping the various components of your software in separate repositories, monorepos unify them in a single spot. This means that each package is living in its own folder, which simplifies making changes across modules of a single piece of software. It makes them easier to test in concert with each other, and it can also make releases easier. Yet, everything is a tradeoff, so this approach often requires new tools. The most popular one is Lerna, which helps you manage monorepos through a simple CLI interface.
Full support for running Greenkeeper on monorepos
We originally designed Greenkeeper to help with the opposite of monorepos: many small modules, each with its own individual `package.json` in the project root. So far, Greenkeeper has simply ignored all other `package.json` files in a repo, but no more! Here’s how it works now:
- If you still only have a single package.json in the project root, everything works exactly as it did before.
- In all other cases, Greenkeeper will introduce a config file called greenkeeper.json to your repo. This helps you define how you’d like to receive updates: you can collect package files in groups. You can selectively ignore dependencies on group level as well.
- When updates arrive, Greenkeeper handles all package files in a group together. Say your monorepo has a packages folder with 16 sub-packages that you’ve all got in one group. Greenkeeper will only open one branch instead of 16, only run your tests once instead of 16 times, and only open one issue or PR instead of 16, if any. This cuts down on noise a lot, but still allows you to identify problems, since individual dependencies are still isolated from each other.
- If you have split your packages in many sub-directories, for example ./frontend and ./backend, you can define groups to receive separate updates for each sub-directory.
- If you edit and mess up your greenkeeper.json, don’t worry! Greenkeeper will open an issue and do its best to let you know where the problems are.
And of course all this also works with your lockfiles! đź”’
Better support for dependencies from monorepos
If you can have a monorepo, so can anyone else, including the projects your projects depend on. Releases from these repositories thus have the potential to generate a lot of noise. Take for example when Angular releases updates to 17 modules at once. Greenkeeper will now group updates from projects like Angular, Babel, React, PouchDB and Jest for you, and update them all in one go.
Since there’s no inherent way of knowing which modules belong to which monorepo, we’re introducing Monorepo Release Definitions for Greenkeeper. This is an open list of popular monorepos and their constituent modules, and anyone can add or update definitions via a pull request. In fact, they’ve already done so! With this, Greenkeeper can determine which dependencies belong together, and group them together for your convenience.
Other Improvements
A New Greenkeeper-Specific Config File
Instead of adding even more information to your package.json, we’ve decided that you can put your Greenkeeper configuration into its own file called greenkeeper.json. All the configuration generated by Greenkeeper for monorepos automatically goes into these. Additionally, your ignored dependencies and anything else we may make configurable in the future will live in there too.
Custom Commit Messages
Thanks to Greenkeeper user Arcanemagus you can now have custom commit messages for Greenkeeper’s commits. Not happy with devDependency updates being marked as a chore? No problem, you can call it whatever you want now. Have a custom commit convention that uses emoji instead of alphanumeric characters? Also no problem. In fact: awesome! 🦄
Yearly Billing for All Plans
We’ve also added yearly billing for all users that subscribe to Greenkeeper directly (and not via GitHub Marketplace, which already had this feature). You can switch to yearly billing in the account dashboard and enjoy a non-trivial 16.66666667% discount over monthly billing! In more human terms: you get 12 months for the price of 10. Ka-ching! 💰
đź”’ Better Lockfile Support
There’s been a lot of work done to extend Greenkeeper-Lockfile, both by the community and ourselves. Together we’ve added support for the following CI services in the last couple of months:
…which means Greenkeeper-Lockfile now supports 10 different CI services.
Thanks, all of you!
Naturally, Greenkeeper wouldn’t be what it is today if it weren’t for you, our several thousand users and customers all over the world. It’s a constant source of joy seeing your feedback on Twitter and your participation on GitHub. There’s always a bunch of 🍾 emoji in the company Slack whenever someone discovers another well-known company in the log files. You’re even delightful when we’ve broken something and you have to get in touch with support 💚
In other words: thanks! It’s not easy building a bootstrapped business without the luxury (or curse) of external funding, but it’s definitely worth it with lovely users like this:
Thanks for reading!
🤖 🌴
