Watching every release is not monitoring. It is a second inbox with a package name on it.
Open your package.json. Count the direct dependencies. Now multiply by roughly one release every few weeks, and you have the number of events per year that a tool watching your dependencies could send you.
For a medium project that is a few thousand. Nobody reads a few thousand of anything.
So the real question is not how to get notified about dependency changes. Everything already offers that, and it is why the notifications are off. The question is how to hear about the small number that change what you should do this week.
What the existing tools actually answer
GitHub's watch releases answers "did this repository tag something". True, complete, and undifferentiated. Version 2.4.1 with a typo fix in the README arrives exactly like the release that drops your Node version.
Dependabot and Renovate answer "is a newer version available, and does it build". That is more than a notification, it is a pull request, which is genuinely great and also why the repository fills with them. Both have grouping and scheduling, and everyone eventually turns both up until the PRs arrive weekly and get merged in a batch without being read.
Advisory feeds answer "is there a published vulnerability". This is the highest signal channel available and you should have it on. It also only covers one kind of change, and it fires on severity in general rather than on whether you use the affected path.
A changelog answers everything, at the cost of you reading it.
Each one is correct about a different question. None of them is answering yours, which is: what changed that I have to do something about.
The four things that are actually worth an interruption
Out of everything a dependency can do, four categories are worth stopping for, and everything else is reading material.
It broke a promise you rely on. A removed API, a changed default, a stricter peer requirement, a runtime version dropped. The version number is supposed to tell you this and frequently does not, because the maintainer's idea of a breaking change is scoped to the whole library and yours is scoped to the part you call.
It became a liability. An advisory that touches a path you use. A licence change. A maintainer handover to an owner you do not know. An archived repository.
It removed a workaround you are carrying. This is the one nobody watches for and it pays the best. You wrote a hack eighteen months ago because a thing was not supported. It is supported now, and nothing will ever tell you, because your workaround is not in their changelog.
Someone else's dependency changed under yours. The transitive case, where nothing about your direct list changed at all.
Notice how little of that is visible from a version bump, and how much of it requires knowing something about your project rather than about the package.
What to do, in order of effort
Turn on advisories, turn off release watching. Advisories have a decent ratio. Release watching does not, and it is the single largest source of dependency noise for most people. You are not going to read them, so stop pretending and reclaim the channel.
Watch a handful of things properly instead of everything shallowly. For the five or six libraries your product would actually be in trouble without, subscribe to the release feed directly and read them. Five is a number a person can sustain. Two hundred is not, and the tool that offers two hundred is not offering you more coverage, it is offering you the same zero coverage with more email.
Pin the version and read the diff when you choose to move. Most dependency risk is not "I did not hear". It is "I upgraded without looking". A scheduled upgrade day where you read what you are taking beats a stream of notifications you do not read.
Write down what you would actually change your week for. For each of your top dependencies: what would have to happen for you to open the editor today. If nothing would, it does not need to interrupt you, and you have just discovered that most of your list belongs on a page rather than in a notification.
Most dependency notifications answer "is there something new". The only useful question is "is there something I have to do".
The part that is genuinely hard
Everything above narrows the direct list. The changes that actually hurt tend to arrive from outside it.
The vendor whose API you call announces a deprecation on their blog, not in a package. The regulator changes something about the data you store. A company you depend on gets acquired. A cloud provider changes a default. None of that has a version number and none of it appears in any dependency tool, because none of those are dependencies in the sense your package manager understands.
But they are dependencies in the sense that matters, and a monitoring setup that only reads your lockfile is watching the half of your stack that already has the best tooling and ignoring the half that has none.
The honest fix is to write the list by hand. Your direct packages, plus the vendors, the APIs, the regulators, the platforms. It is usually somewhere between twenty and sixty things, and it takes an afternoon. Once it exists, it turns out to be the input every monitoring decision needed, and the reason none of the tools worked before is that none of them had it.
Why I care about this
I built something that starts from exactly that list. You hand it a package.json, a requirements.txt or a go.mod, it proposes what it thinks you depend on, and you tick what is true. Then you add the half no file knows about: the vendors, the platforms, the regulators, the people.
The one design choice worth stealing even if you build this yourself: direct dependencies only, never the lockfile. A lockfile is a transitive closure, and anything that believes you depend on nine hundred libraries is attached to everything, which is arithmetically identical to being attached to nothing.
The list is worth writing even if you never install anything. It is the difference between monitoring your dependencies and being notified about them.
Originally published at thalmas.com/blog/watching-your-dependencies.
Top comments (0)