Did anyone try Renovatebot[1]? It should be OpenSource and endorsed from OpenSSF and Google. Main advantages I see is batched updates, which reduce a bit the dependency update spam.
Ask HN: How do you work with Dependabot?
31–40 of 46 posts
Re: Ask HN: How do you work with Dependabot?
#32Disabling it on a repository is one of the first things I do. I tend not to like how noisy it is on Node project. Instead, I have scheduled tasks which audit periodically.
Re: Ask HN: How do you work with Dependabot?
#33A more useful bot would be named Undependabot. Cuts complexity caused by the dependency bloat by suggesting to remove random dependencies and linking to http://vanilla-js.com/. Flags any PR that introduces new dependencies, and computes the cost in time and money these new dependencies should cost in the long term, and the time and bandwidth usage it adds to each (CI) build. Adds badges to developers and teams that reduce their dependencies or have few or none. Rejects any PR introducing (transitive) dependencies to packages from jonschlinkert.
Re: Ask HN: How do you work with Dependabot?
#34Earlier quoted context omitted.
> the admin interface, which obviously, we don't explicitly test This... is not obvious. It broke a part of your software which you care about. You care, it caused a problem, so it should be tested.
You routinely write unit tests for dependent packages in your apps?
No. This is what integration tests are for.
These kinds of failures are super annoying, but it’s the sort of thing that e2e and canary releases should help you get some coverage on.
Despite the marketing, unit tests are pretty fragile, especially in code with lots of deps (another good reason to limit deps)
Re: Ask HN: How do you work with Dependabot?
#35Same feelings. I like the idea but in practice I don’t trust it. Or rather, I don’t trust package maintainers to adhere to semver. I prefer to manually go through dependencies updating one at a time and reading the change logs. I usually do this in batch. Peace of mind is worth more than the hour saved every week or two. I do really like the tool that flags security issues with packages though.
You can still use dependabot to assist you with this. Let it only open PRs and it will show you the commits and changelog or at least a link to the source project in the PR description.
Having a PR already open with a full test run done in CI saves a ton of time, at least in repos with a lot of dependencies.
Re: Ask HN: How do you work with Dependabot?
#36I've been using Depfu for a while and I think it handles some of the biggest pain points with Dependency spam.
- Package releases don't get PRs in their first 24 hours unless they are for security issues, so you don't get noise if there's a yank or a quick patch for a bug in the latest release
- You can set development (or production!) packages to only update once a week
- Packages that are known to have a very frequent release cadence (AWS SDK subcomponents, looking at you)_get pushed to a much slower PR pace so that you only update them 2x/month, etc.
- This might be fixed now, but it had much nicer auto-merge behavior for releases that passed CI.
- With Yarn, it can run `yarn-deduplicate` after updates to trim down shared dependency bloat.
FWIW we still use Dependabot for security patches only because they seem to get picked up a few hours earlier. We also have much tighter lock rules on some JS packages which seem to make breaking changes on patch/minor releases.
Re: Ask HN: How do you work with Dependabot?
#37Dependabot only works reliably with lots of integration tests.
Re: Ask HN: How do you work with Dependabot?
#38I’ve only really experienced Dependabot for libraries, rather than applications, and in that context I don’t really understand why it exists or why people use it.
If you’re making a library and it bumps the lower version bounds of your dependencies, it’s doing something that’s actively slightly harmful. It’d be fine to notify you about major/incompatible version bumps, maybe even try them to see if they work (though certainly don’t apply the change automatically—a major version bump on a dependency is regularly a breaking change even if your tests still pass). But minor/patch/compatible releases that are already accepted by the version specifier? You shouldn’t be bumping those. Test against them if you like, maybe update your testing lockfile, but generally speaking the versions of libraries are an application concern, and your library should not be trying to dictate it.
(I must admit that the whole concept of compatible ranges is in practice slightly broken through and through, though it seldom causes trouble. I would love to have tooling that actively minimised dependency versions: “1.2.3? Turns out the newest functionality you’re depending on is from 1.1.0, so I’ll reduce the spec to ‘1.1’.” This would, of course, need to be paired with checking that you don’t accidentally use newer functionality—at the least, running your tests on minimum versions, preferably stronger API checks. Overall it’s the sort of thing that is difficult to make robust by any means in the likes of JavaScript and Python, but which could sanely be done in Rust, and there’s enough interest that I think something will probably happen within the next decade.)
But applications? Sure, this is where Dependabot has an actual sane purpose. But presuming people tend to have it configured in similar ways to how they configure it in libraries… ugh. I’d still rather just do roughly what it does manually from time to time.
Re: Ask HN: How do you work with Dependabot?
#39A more useful bot would be named Undependabot. Cuts complexity caused by the dependency bloat by suggesting to remove random dependencies and linking to http://vanilla-js.com/ . Flags any PR that introduces new dependencies, and computes the cost in time and money these new dependencies should cost in the long term, and the time and bandwidth usage it adds to each (CI) build. Adds badges to developers and teams that…
Mind you, adding dependencies does not imply increasing build artefact sizes. Suppose A depends on B and C, and B and C contain similar functionality, then collaborate to extract that into D, so that A ends up with one more dependency, but less code net. (This is the theory of the tiny package philosophy widely found in npm. But in practice, they often seem to clog things up awfully with runtime type checking and the likes, or just adding a pointless level of indirection, so that they make things worse. But the underlying idea is sound.)
—⁂—
For the rest, most of the pieces already exist and are not particularly difficult to put together, though a more polished presentation of a holistic experience (if you’ll pardon the expression) could be desirable.
For suggesting dependencies to remove and flagging undesirable dependencies, that’s entirely a data problem: you want another audit/code review/advisory database, really. (You could take it further and identify automatic code translations, but that’d be quite a bit more work, though again the bones that you need generally already exist.)
For pointing out dependency costs: such metric monitoring is already widely used, especially in larger projects that want to catch regressions immediately.
Re: Ask HN: How do you work with Dependabot?
#40Earlier quoted context omitted.
> the admin interface, which obviously, we don't explicitly test This... is not obvious. It broke a part of your software which you care about. You care, it caused a problem, so it should be tested.
You routinely write unit tests for dependent packages in your apps?
Yes, we routinely write tests that interact with dependencies to make sure our application works.