Proposal: remove dependencies.io

[karuto]

TL;DR

I would like to propose to remove dependencies.io.

Reasons: I do not agree with its philosophy; the tool brings more downside than upside; I have no bandwidth to keep all packages updated all the time.

Context

I do not agree with the "always automatically update" philosophy

Automatic dependency update is a sensitive topic in the open source community and I believe both sides have valid arguments. There's no right or wrong in the absolute sense.

I personally lean towards the "if it ain't broke, don't fix it" camp. We shouldn't update dependencies for the sake of getting them updated.

At best, they do nothing and the system works as expected. At worst, they are a headache to debug and mitigate. I think we should only update a dependency if it provides a substantial upside that actually affects our usages.

The tool brings more downside than upside

Upside:

• It alerts when there's a new version available, and creates an automatic PR to bump the version.

Downside:

• Lots of noise. We currently set up alerts (automatic PRs) for all semver levels: patch, minor and major. This gets overwhelming in the PR section really quickly with 20+ dependencies.io bot PRs that updates daily. We can change the config, sure, but the fundamental problems are still here.
• It isn't helpful: the bot just bumps the version blindly, without actually providing help on prioritizing which package to update, and gauging the difficulties of making it compatible. I know that may not be its job, but it isn't improving the dev experience for sure.
• It's misleading: the bot PRs suggest that we can simply click merge and make the package updated to work, which often isn't the case. I've fallen into this trap before and caused a broken build.

I have no bandwidth to keep all packages updated all the time

I would love to live in a world where all dependency packages are up to date, all the time. But I can't even guarantee that for my team's flagship projects, there's no way I can keep it up here.

I believe getting the latest dependencies for this project is a low priority item, therefore I don't find dependencies.io helpful enough to keep.

Feedback welcome @lastquestion @matteofigus @nickbalestra @jrolfs @mattiaerre

[jrolfs]

I think it's worth trying to tune dependencies.io (or possibly using another service/bot that better suites our needs) before we remove it entirely. I'd be willing to open a PR to do so.

[jrolfs]

If it continues to add more noise than value, however, I'd side with you 🤝 over the bot 🤖 (for the record).

[karuto]

@jrolfs I thought of that, maybe we could limit the alerts to just major version updates. But I feel like that would only reduces noise (downside no.1) but not addressing the other downsides. Open for changing my mind though! 😆

[karuto]

I'll give it another week for this issue if no one cares enough I'll proceed with my original proposal.

[matteofigus]

I think it's worth trying to tune dependencies.io (or possibly using another service/bot that better suites our needs) before we remove it entirely. I'd be willing to open a PR to do so.

Yes! If you look at the config, I think you have the setting for strict versioning on the package.json on the root, and weak (^) versioning on style-guide. If you like, you can do weak versioning for all, so you can have less PRs.

I personally lean towards the "if it ain't broke, don't fix it" camp. We shouldn't update dependencies for the sake of getting them updated.

The way I see it, the updates often could be bugfixes or security updates, so I always prefer to get to the latest version. Something may look not broken, but is it really? I generally find easier to merge many little green PRs than big few red ones. There are a number of blogpost like this one that discuss this kind of topics.

It's misleading: the bot PRs suggest that we can simply click merge and make the package updated to work, which often isn't the case. I've fallen into this trap before and caused a broken build.

In regards of the PR that broke the things, if that was green, the way I would react would be to create additional testing to prevent a false positive to be merged, rather than reducing the automation involved.

Conclusion: I shared my 2 cents here as I have been tagged, but I don't own this repo so feel free to ignore. I think you @karuto should discuss with the other current owners and base your decision on that. 👋