A corollary to this is that you want to upstream any changes that you make to your dependencies. Every change that you make to a dependency adds effort when you need to update that dependency.
It makes so much sense. Never been in a situation where I had to make changes to the dependency. But if I ever do that I am glad to have learned this principle.
Agree. Looking at my past scars I would say that updating regularly helps avoiding having multiple dependencies breaking at the same time, which turns the update in a nightmare, and avoid using a potentially old syntax. Syntax you’ll be forced to update at some point.
So the often, the merrier.
Side Notes: Tests helps a lot, you don’t want a manager on your neck during a update because of a security audit.
A few jobs ago I got stuck on a death-march project that ended up involving a massive dependency update on a codebase that hadn’t been through an update in literal years. And was using multiple different methods of dependency management – some things installed via package manager, some vendored directly, some as git submodules…
Now, every place I work at, if they don’t have both a single, simple dependency management workflow and at least a monthly, if not twice-a-month or outright weekly, cadence of automatically checking for and applying dependency updates, those are the first things I start pushing for and setting up.
Making it frequent makes it routine. Making it routine makes it safe and reliable. I like safe and reliable. Getting a codebase to the point where you can say “the dependabot PR passed CI, just merge it and let it get deployed” is so very nice.
Yeah, exactly — having multiple things that need fixing at the same time (often because to update one thing you have to update a different piece it interacts with, which is no longer compatible with this other bit, and so on and on…) is the worst part. Doing it in tiny bite-sized pieces at a time of your choosing just makes it less tedious in the long run.
Should they be updated? Yes. It’s pretty costly to do so though. So frankly I also want to say: “using dependencies saves you less time than you initially think.”
Yes, I remember a decade ago complaining about Autoconf and having to manually configure the three dependencies required to build your average open source C application. A decade later, those C programs still build just fine while my npm based libs stop working within days unless I lock library versions.
I’m always wary of giving a CI system write access to actually change the repo. Incidents like the recent CircleCI one come to mind. If the automation just opens a pull request (or equivalent), that seems pretty helpful though.
In practice I’ve found tools like Renovate and Dependabot are almost great, but still have too many small annoyances to be worth the effort over just doing the updates myself. Things like (I forget which one does this) opening one PR per dependency, but then not rebasing the remaining open PRs automatically when one is merged.
I’ve committed heavily to Renovate at work and it’s paying off. I have ~two dozen repos under my care right now and they have similar but not the same dependencies. Keeping everything relatively up to date is a challenge because of the number of repos and the sometimes long dependency resolution process in Poetry (although it’s faster in 1.4.0).
Absolutely! With excellent tools out there like Renovate that support dozens of ecosystems and has complex functionality for organising updates, it’s almost hard not to keep up to date, if you are able to schedule the time.
I’ve recently been building some tooling (https://dmd.tanna.dev) for providing more insight including things like “am I using end of life software”
There’s a ton of comments here already but I really wish dependabot could re-group all the PRs with passing tests together. If that fails then just stop there or try to bisect.
I love dependabot, but the tool of merging a PR, waiting for other PRs to update/rebase (due to lockfile) is maddening to me. Either I forget halfway what I was doing and leave deps unupgraded or spend more time merging than I would like.
I’m just now wondering if merge queue helps with this, I’ve not tried it.
Unsure why most teams don’t set a task to auto-update dependencies once a month or so. I heard that GitHub recently notified repo managers of outdated dependencies with n-days which is good.
I use a combination of dependabot and a custom bot to automate this on GitHub actions. For projects that have a robust test suite, I’m happy for them to merge minor and patch releases automatically if the test suite passes. e.g. https://github.com/CloudCannon/pagefind/pull/252
A corollary to this is that you want to upstream any changes that you make to your dependencies. Every change that you make to a dependency adds effort when you need to update that dependency.
It makes so much sense. Never been in a situation where I had to make changes to the dependency. But if I ever do that I am glad to have learned this principle.
Agree. Looking at my past scars I would say that updating regularly helps avoiding having multiple dependencies breaking at the same time, which turns the update in a nightmare, and avoid using a potentially old syntax. Syntax you’ll be forced to update at some point.
So the often, the merrier.
Side Notes: Tests helps a lot, you don’t want a manager on your neck during a update because of a security audit.
A few jobs ago I got stuck on a death-march project that ended up involving a massive dependency update on a codebase that hadn’t been through an update in literal years. And was using multiple different methods of dependency management – some things installed via package manager, some vendored directly, some as git submodules…
Now, every place I work at, if they don’t have both a single, simple dependency management workflow and at least a monthly, if not twice-a-month or outright weekly, cadence of automatically checking for and applying dependency updates, those are the first things I start pushing for and setting up.
Making it frequent makes it routine. Making it routine makes it safe and reliable. I like safe and reliable. Getting a codebase to the point where you can say “the dependabot PR passed CI, just merge it and let it get deployed” is so very nice.
Yeah, exactly — having multiple things that need fixing at the same time (often because to update one thing you have to update a different piece it interacts with, which is no longer compatible with this other bit, and so on and on…) is the worst part. Doing it in tiny bite-sized pieces at a time of your choosing just makes it less tedious in the long run.
Should they be updated? Yes. It’s pretty costly to do so though. So frankly I also want to say: “using dependencies saves you less time than you initially think.”
Yes, I remember a decade ago complaining about Autoconf and having to manually configure the three dependencies required to build your average open source C application. A decade later, those C programs still build just fine while my npm based libs stop working within days unless I lock library versions.
I have a CI job that runs every month to update deps. I’ve been reasonably happy with it.
I’m always wary of giving a CI system write access to actually change the repo. Incidents like the recent CircleCI one come to mind. If the automation just opens a pull request (or equivalent), that seems pretty helpful though.
In practice I’ve found tools like Renovate and Dependabot are almost great, but still have too many small annoyances to be worth the effort over just doing the updates myself. Things like (I forget which one does this) opening one PR per dependency, but then not rebasing the remaining open PRs automatically when one is merged.
Yeah, the bot just opens a PR on the first of the month. I have to go through and manually approve it before it gets merged.
Not to “well actually” but [it is possible with Renovate]https://docs.renovatebot.com/configuration-options/#rebasewhen) to specify not to rebase all the time
In that case, I’ll claim it was Dependabot I was having trouble with ;-)
As an example I have set up a repository with both dependabot and mergify, … it works quite well.
dependabot opens an MR, github actions run the CI workflow, and mergify only merges if its green.
Haven’t used that combination for a real project though.
I’ve committed heavily to Renovate at work and it’s paying off. I have ~two dozen repos under my care right now and they have similar but not the same dependencies. Keeping everything relatively up to date is a challenge because of the number of repos and the sometimes long dependency resolution process in Poetry (although it’s faster in 1.4.0).
Absolutely! With excellent tools out there like Renovate that support dozens of ecosystems and has complex functionality for organising updates, it’s almost hard not to keep up to date, if you are able to schedule the time.
I’ve recently been building some tooling (https://dmd.tanna.dev) for providing more insight including things like “am I using end of life software”
There’s a ton of comments here already but I really wish dependabot could re-group all the PRs with passing tests together. If that fails then just stop there or try to bisect.
I love dependabot, but the tool of merging a PR, waiting for other PRs to update/rebase (due to lockfile) is maddening to me. Either I forget halfway what I was doing and leave deps unupgraded or spend more time merging than I would like.
I’m just now wondering if merge queue helps with this, I’ve not tried it.
Unsure why most teams don’t set a task to auto-update dependencies once a month or so. I heard that GitHub recently notified repo managers of outdated dependencies with n-days which is good.
I use a combination of dependabot and a custom bot to automate this on GitHub actions. For projects that have a robust test suite, I’m happy for them to merge minor and patch releases automatically if the test suite passes. e.g. https://github.com/CloudCannon/pagefind/pull/252