8 ms·
Turn Dependabot off
- apitman 8mo agoI find dependabot very useful. It's drives me insane and reminds me of the importance of keeping dependencies to an absolute minimum.
- keyle 8mo agoI agree, I don't have a ton of projects out there though.
- mechsy 8mo agoAbsolutely! This is oftentimes my first easy task in the morning to kick things off. For many teams the temptation to let dependencies ‚rot‘ is real, however I have found a reliable way to keep things up-to-date is enabling dependabot and merging relentlessly, releasing often etc. If your test suite is up to the task you’ll find defects in new updates every now and then, but for me this has even led to some open source contributions, engaging with our dependencies’ maintainers and so on. So I think overall it promotes good practices even though it can be a bit annoying at times.
- samhclark 8mo agoThis makes sense to me. I guess I'll start hunting for the equivalent of `govulncheck` for Rust/Cargo. Separately, I love the idea of the `geomys/sandboxed-step` action, but I've got such an aversion to use anyone else's actions, besides the first-party `actions/*` ones. I'll give sandboxed-step a look, sounds like it would be a nice thing to keep in my toolbox.
- FiloSottile 8mo ago> I've got such an aversion to use anyone else's actions, besides the first-party `actions/*` ones Yeah, same. FWIW, geomys/sandboxed-step goes out of its way to use the GitHub Immutable Releases to make the git tag hopefully actually immutable.
- bpavuk 8mo ago> I guess I'll start hunting for the equivalent of `govulncheck` for Rust/Cargo. how about `cargo-audit`?
- mirashii 8mo agocargo-audit is not quite at an equivalent level yet, it is lacking the specific features discussed in the post that identify the vulnerable parts of the API surface of a library. cargo-audit is like dependabot and others here in that it only tells you that you're using a version that was vulnerable, not that you're using a specific API that was vulnerable.
- hobofan 8mo agoSaddly, since it relies on a Cargo.lock to be correct it also is affected by bugs that place dependencies in the Cargo.lock, but are not compiled into the binary. e.g. weak features in Cargo currently cause unused dependencies to show up in the Cargo.lock.
- conradludgate 8mo agohttps://rustsec.org/ https://rustsec.org/
- LawnGnome 8mo agoAlthough, unfortunately, not all RustSec advisories include function-level vulnerability metadata in practice.
- LawnGnome 8mo agoI was actually working on this last week, funnily enough. I've been working on a capability analysis tool for Rust, and if you're already generating a call graph via static analysis, taking that and matching it against the function-level vulnerability data that exists in RustSec isn't that hard. Hopefully I'll have something out next week.
- literallyroy 8mo agoThe go ecosystem is pretty good about being backwards compatible. Dependabot regular update prs once a week seems like a good option in addition to govulncheck.
- seg_lol 8mo agoBe wary of upgrading dependencies too quickly. This is how supply chain incursions are able to spread too quickly. Time is a good firwall.
- Hamuko 8mo ago>Time is a good firwall. That just reminds me that I got a Dependabot alert for CVE-2026-25727 – "time vulnerable to stack exhaustion Denial of Service attack" – across multiple of my repositories.
- esafak 8mo agoThey fixed that last summer: https://github.blog/changelog/2025-07-01-dependabot-supports-configuration-of-a-minimum-package-age/ https://github.blog/changelog/2025-07-01-dependabot-supports...
- jamietanna 8mo agoYep, and we've had it for a while in Renovate too: https://docs.renovatebot.com/key-concepts/minimum-release-age/ https://docs.renovatebot.com/key-concepts/minimum-release-ag... (I'm a Renovate maintainer) (I agree with Filippo's post and it can also be applied to Renovate's security updates for Go modules - we don't have a way, right now, of ingesting better data sources like `govulncheck` when raising security PRs)
- ImJasonH 8mo agoHere's a Go mod proxy-proxy that lets you specify a cooldown, so you never get deps newer than N days/weeks/etc https://github.com/imjasonh/go-cooldown https://github.com/imjasonh/go-cooldown It's not running anymore but you get the idea. It should be very easy to deploy anywhere you want.
- bityard 8mo agoA firwall also makes a good firewall, once ignited.
- bpavuk 8mo agois there a `govulncheck`-like tool for the JVM ecosystem? I heard Gradle has something like that in its ecosystem. search revealed Sonatype Scan Gradle plugin. how is it?
- wpollock 8mo agoIt's been a few years, but for Java I used OWASP: <https://owasp.org/www-project-dependency-check/ https://owasp.org/www-project-dependency-check/>, which downloads the NVD (so first run was slow) and scans all dependicies against that. I ran it from maven as part of the build.
- ImJasonH 8mo agoGovulncheck is one of the Go ecosystem's best features, and that's saying something! I made a GitHub action that alerts if a PR adds a vulnerable call, which I think pairs nicely with the advice to only actually fix vulnerable calls. https://github.com/imjasonh/govulncheck-action https://github.com/imjasonh/govulncheck-action You can also just run the stock tool in your GHA, but I liked being able to get annotations and comments in the PR. Incidentally, the repo has dependabot enabled with auto-merge for those PRs, which is IMO the best you can do for JS codebases.
- silverwind 8mo agoGovulncheck is good, but not without false-positives. Sometimes it raises "unfixable" vulnerabilities and there's still no way to exclude vulnerabilties by CVE number.
- ImJasonH 8mo agoI haven't experienced that (that I know of), do you have an example handy?
- esafak 8mo agoI automate updates with a cooldown, security scanning, and the usual tests. If it passes all that I don't worry about merging it. When something breaks, it is usually because the tests were not good enough, so I fix them. The next step up would be to deploy the update into a canary cluster and observe it for a while. Better that than accrue tech debt. When you update on "your schedule" you still should do all the above, so why not just make it robust enough to automate? Works for me.
- FiloSottile 8mo agoFor regular updates, because you can minimize but not eliminate risk. As I say in the article that might or might not work for your requirements and practices. For libraries, you also cause compounding churn for your dependents. For security vulnerabilities, I argue that updating might not be enough! What if your users’ data was compromised? What if your keys should be considered exposed? But the only way to have the bandwidth to do proper triage is by first minimizing false positives.
- duskdozer 8mo ago>For libraries, you also cause compounding churn for your dependents. This is the thing that I don't really understand but that seems really popular and gaining. The article's section "Test against latest instead of updating" seems like the obvious thing to do, as in, keep a range of compatible versions of dependencies, and only restrict this when necessary, in contrast to deployment- or lockfile-as-requirement which is restricted liberally. Maybe it's just a bigger deal for me because of how disruptive UI changes are.
- SamuelAdams 8mo agoWhat’s nice about Dependabot is that it works across multiple languages and platforms. Is there an equivalent to govulncheck for say NPM or Python?
- mirashii 8mo ago> Is there an equivalent to govulncheck for say NPM or Python? There never could be, these languages are simply too dynamic.
- robszumski 8mo agoI commented elsewhere but our team built a custom static analysis engine for JS/TS specifically for the dep update use-case. It was hard, had to do synthetic execution, understands all the crazy remapping and reexporting you can do, etc. Even then it’s hard to penetrate a complex Express app due to how the tree is built up.
- woodruffw 8mo agoIn practice this isn’t as big of a hurdle as you might expect: Python is fundamentally dynamic, but most non-obfuscated Python is essentially static in terms of callgraph/reachability. That means that “this specific API is vulnerable” is something you can almost always pinpoint usage for in real Python codebases. The bigger problem is actually encoding vulnerable API information (not just vulnerable package ranges) in a way that’s useful and efficient to query. (Source: I maintain pip-audit, where this has been a long-standing feature request. We’re still mostly in a place of lacking good metadata from vulnerability feeds to enable it.)
- mirashii 8mo agoThe thing is that almost always isn't good enough. If it can't prove it, then a human has to be put back in the loop to verify and assert, and on sensitive timelines when you have regulatory requirements on time to acknowledge and resolve CVEs in dependencies.
- focusedmofo 8mo agoIs there an equivalent for JS/TS?
- nfm 8mo agoThe number of ReDoS vulnerabilities we see in Dependabot alerts for NPM packages we’re only using in client code is absurd. I’d love a fix for this that was aware of whether the package is running on our backend or not. Client side ReDoS is not relevant to us at all.
- adverbly 8mo agoSeriously! We also suffer from this. Although in some cases it's due to a Dev dependency. It's crazy how much noise it adds specifically from ReDoS...
- robszumski 8mo agoTotally hear you on the noise…but we should want to auto-merge vs ignore, no? Given the right tooling of course.
- dotancohen 8mo agoNo
- UqWBcuFx6NV4r 8mo agoWe could just skip some steps and I could send you a zip file of malware for you to install on your infra directly if you’d like.
- deleted 8mo ago[deleted]
- monkpit 8mo agoReDoS cves in your dev dependencies like playwright that could literally never be exploited, so annoying.
- staticassertion 8mo agoTBH I Think that DoS needs to stop being considered a vulnerability. It's an availability concern, and availability, despite being a part of CIA, is really more of a principle for security rather than the domain of security. In practice, availability is far better categorized as an operational or engineering concern than a security concern and it does far, far more harm to categorize DoS as a security conern than it does to help. It's just a silly historical artifact that we treat DoS as special, imo.
- mehagar 8mo agoIs there an equivalent for the JS ecosystem? If not, having Dependabot update dependencies automatically after a cooldown still seems like a better alernative, since you are likely to never update dependencies at all if it's not automatic.
- mook 8mo agoToo bad dependabot cooldowns are brain-dead. If you set a cooldown for one week, and your dependency can't get their act together and makes a release daily, it'll start making PRs for the first (oldest) release in the series after a week even though there's nothing cool about the release cadence.
- kleyd 8mo agoThe cooldown is to allow vulnerabilities to be discovered. So auto update on passing tests, which should include an npm audit check.
- seattle_spring 8mo agoRenovateBot supports a ton of languages, and ime works much better for the npm ecosystem than Dependabot. Especially true if you use an alternative package manager like yarn/pnpm.
- snowhale 8mo ago[dead]
- robszumski 8mo agoWe’ve built a modern dependabot (or works with it) agent: fossabot analyzes your app code to know how you use your dependencies then delivers a custom safe/needs review verdict per upgrade or packages groups of safe upgrades together to make more strategic jumps. We can also fix breaking changes because the agents context is so complete. https://fossa.com/products/fossabot/ https://fossa.com/products/fossabot/ We have some of the best JS/TS analysis out there based on a custom static analysis engine designed for this use-case. You get free credits each month and we’d love feedback on which ecosystems are next…Java, Python? Totally agree with the author that static analysis like govulncheck is the secret weapon to success with this problem! Dynamic languages are just much harder. We have a really cool eval framework as well that we’ve blogged about.
- AutumnsGarden 8mo agoI think python and go could be great use cases
- MattIPv4 8mo agoAre y'all aware your agent's name clashes with an established and rather popular streaming bot/tool, https://fossabot.com https://fossabot.com ?
- tracker1 8mo agoI kind of wish Dependabot was just another tab you can see when you have contributor access for a repository. The emails are annoying and I mostly filter, but I also don't want a bunch of stale PRs sitting around either... I mean it's useful, but would prefer if it was limited to just the instances where I want to work on these kinds of issues for a couple hours across a few repositories.
- BHSPitMonkey 8mo agoYou can add a dependabot.yml config to regulate when Dependabot runs and how many PRs it will open at a time: https://docs.github.com/en/code-security/reference/supply-chain-security/dependabot-options-reference https://docs.github.com/en/code-security/reference/supply-ch...
- operator-name 8mo agoThe refined github extension[0] has some defaults that make the default view a little more tolerable. Past that I can personally recommend Renovate, which supports far more ecosystems and customisation options (like auto merging). [0]: https://github.com/refined-github/refined-github https://github.com/refined-github/refined-github
- curtisf 8mo agoIsn't it? You can have Dependabot enabled, but turn off automatic PRs. You can then manually generate a PR for an auto-fixable issue if you want, or just do the fixes yourself and watch the issue number shrink.
- TZubiri 8mo agoComing from someone with an almost ascetic dependency discipline, I look at some meta-dependencies as an outsider (dependabot, pnpm/yarn, poetry/venv/pipenv, snap/flatpak), a solution to too many dependencies that is yet another dependency, it feels like trying to get out of a hole by digging. I think that for FOSS the F as in Gratis is always going to be the root cause of security conflicts, if developers are not paid, security is always going to be a problem, you are trying to get something out of nothing otherwise, the accounting equation will not balance, exploiting someone else is precisely the act that leaves you open to exploitation (only according to Nash Game Theory). "158 projects need funding" IS the vector! I'm not saying that JohnDoe/react-openai-redux-widget is going to go rogue, but with what budget are they going to be able to secure their own systems? My advice is, if it ever comes the point where you need to install dependencies to control your growing dependency graph? consider deleting some dependencies instead.
- 1718627440 8mo ago> for FOSS the F as in Gratis Isn't FOSS a combination of the diverging ideas of "Open Source" and "Free Software"? The "Free" in "Free Software" very much does not mean "Gratis".
- TZubiri 8mo agoYes, it's a joke. The Free in Free Software is sold as being Free as in Freedom to devs by recruiters of the cause, however the bulk of actual consumers see Free Software as equivalent to Open Source and the defining characteristic for them is Free as in Gratis.
- 1718627440 8mo agoHonestly, that whole "free as in X" problem to me seems like an English only problem. As an ESL I perceive "free" to be the adjective to "freedom" by default and the other meaning to be a contraction of "free of charge".
- 8mo ago
- indiestack 8mo agoThe govulncheck approach (tracing actual code paths to verify vulnerable functions are called) should be the default for every ecosystem, not just Go. The fundamental problem with Dependabot is that it treats dependency management as a security problem when it's actually a maintenance problem. A vulnerability in a function you never call is not a security issue — it's noise. But Dependabot can't distinguish the two because it operates at the version level, not the call graph level. For Python projects I've found pip-audit with the --desc flag more useful than Dependabot. It's still version-based, but at least it doesn't create PRs that break your CI at 3am. The real solution is better static analysis that understands reachability, but until that exists for every ecosystem, turning off the noisy tools and doing manual quarterly audits might actually be more secure in practice — because you'll actually read the results instead of auto-merging them.
- staticassertion 8mo agoPart of the problem is that customers will scan your code with these tools and they won't accept "we never call that function" as an answer (and maybe that's rational if they can't verify that that's true). This is where actual security starts to really diverge from the practices we've developed in the name of security.
- unshavedyak 8mo agoWould be neat if the call graph could be asserted easily.. As you could not only validate what vulnerabilities you are / aren't exposed to, but also choose to blacklist some API calls as a form of mitigation. Ensuring you don't accidentally start using something that's proven unsafe.
- adamdecaf 8mo agogovulncheck is the much better answer and we use it. We also let renovate[bot] (similar to dependabot) merge non-major dep updates if tests pass. I hardly notice when deps have small updates. https://github.com/search?q=org%3Amoov-io+is%3Apr+is%3Amerged+sort%3Anewest+author%3Arenovate%5Bbot%5D&type=pullrequests&s=created&o=desc https://github.com/search?q=org%3Amoov-io+is%3Apr+is%3Amerge...
- woodruffw 8mo agoI think this is pretty good advice. I find Dependabot useful for managing scheduled dependency bumps (which in turn is useful for sussing out API changes, including unintended semver breakages from upstreams), but Dependabot’s built-in vulnerability scanning is strictly worse than just about every ecosystem’s own built-in solution.
- aswihart 8mo ago> Dependencies should be updated according to your development cycle, not the cycle of each of your dependencies. For example you might want to update dependencies all at once when you begin a release development cycle, as opposed to when each dependency completes theirs. We're in this space and our approach was to supplement Dependabot rather than replace it. Our app (https://www.infield.ai https://www.infield.ai) focuses more on the project management and team coordination aspect of dependency management. We break upgrade work down into three swim lanes: a) individual upgrades that are required in order to address a known security vulnerability (reactive, most addressed by Dependabot) b) medium-priority upgrades due to staleness or abandonedness, and c) framework upgrades that may take several months to complete, like upgrading Rails or Django. Our software helps you prioritize the work in each of these buckets, record what work has been done, and track your libyear over time so you can manage your maintenance rotation.
- newzino 8mo ago[flagged]
- operator-name 8mo agoThe custom Github Actions approach is very customisable and flexible. In theory you could make and even auto approve bumps. If you want something more structured, I’ve been playing with and can recommend Renovate (no affiliation). Renovate supports far more ecosystems, has a better community and customisation. Having tried it I can’t believe how relatively poor Dependabot, the default tool is something we put up with by default. Take something simple like multi layer dockerfiles. This has been a docker features for a while now, yet it’s still silently unsupported by dependabot!
- esafak 8mo agoThat's what a lack of competition does. Github is entrenched, complacent.
- arianvanp 8mo agoAt this point your steps are so simple id skip GitHub actions security tyre fire altogether. Just run the go commands whilst listening on GitHub webhooks and updating checks with the GitHub checks API. GitHub actions is the biggest security risk in this whole setup. Honestly not that complicated.
- NewJazz 8mo agoI learned recently that self-hosted GHA runners are just VMs your actions have shell access to, and cleanup is on the honor system for the most part. Absolutely wild.
- indiekitai 8mo agoThe core problem is that Dependabot treats dependency graphs as flat lists. It knows you depend on package X, and X has a CVE, so it alerts you. But it has no idea whether you actually call the vulnerable code path. Go's tooling is exceptional here because the language was designed with this in mind - static analysis can trace exactly which symbols you import and call. govulncheck exploits this to give you meaningful alerts. The npm ecosystem is even worse because dynamic requires and monkey-patching make static analysis much harder. You end up with dependency scanners that can't distinguish between "this package could theoretically be vulnerable" and "your code calls the vulnerable function." The irony is that Dependabot's noise makes teams less secure, not more. When every PR has 12 security alerts, people stop reading them. Alert fatigue is a real attack surface.
- 12_throw_away 8mo agoI'm a little hung up on this part: > These PRs were accompanied by a security alert with a nonsensical, made up CVSS v4 score and by a worrying 73% compatibility score, allegedly based on the breakage the update is causing in the ecosystem. Where did the CVSS score come from exactly? Does dependabot generate CVEs automatically?
- amluto 8mo agoI’m kind of curious whether anything is vulnerable to this bug at all. It seems like it depends on calling the offending function incorrectly, which seems about as likely to cause the code using it to unconditionally fail to communicate (and thus have already been fixed) as to fail in a way that’s insecure.
- pornel 8mo agoCVSS has some formula, but it's a fundamentally flawed concept. It's a score for the worst possible case, not for a typical case. It's for ass-covering, not for being informative about the real risk. For every boring API you can imagine someone using it for protecting nuclear launch codes, while having it exposed to arbitrary inputs from the internet. If it's technically possible, even if unrealistically stupid, CVSS treats it the same as being a fact, and we get spam about the sky falling due to ReDoS. This is made worse by GitHub's vulnerability database being quantity-over-quality dumping ground and absolutely zero intelligence in Dependabot (ironic for a company aggressively inserting AI everywhere else)
- NewJazz 8mo agoBesides go, what languages have this type of fidelity for vulnerability scope. Python? Node? Rust?
- KPGv2 8mo agoThis is a symptom of JS culture, where people believe you must at all times and in all places have THE latest version of every library, and you MUST NOT wait more than a day to update your entire codebase accordingly.
- lazyasciiart 8mo agoThis blog post is entirely about Go, and doesn’t mention JS at all.
- fulafel 8mo agoAlert fatigue has been long identified and complained about, this is just a new kind of that. But it's hitting a different set of people.
- p1nkpineapple 8mo agowe struggle with a similar problem at my workplace - vuln alerts from GCP container image scans put a ton of noise into Vanta which screams bloody murder at CVEs in base images which we A) can't fix, and B) aren't relevant as they're not on the hot path (often some random dependency that we don't use in our app). Are there any tools for handling these kind of CVEs contextually? (Besides migrating all our base images to chainguard/docker hardened images etc)
- maciuz 8mo agoI'm working at a medium sized SaaS vendor. We've been using Aikido Code which tries to filter vulnerability impact using AI. Results are generally positive, though we are still struggling with keeping the amount of CVEs down, due to the size of our code bases and the amount of dependencies.
- SahAssar 8mo agoI'd be weary to trust AI with something like that, especially if I had to assert to a third party that we absolutely do not have a vulnerability.
- Chris_Newton 8mo agoDependabot has some value IME, but all naïve tools that only check software and version numbers against a vulnerability database tend to be noisy if they don’t then do something else to determine whether your code is actually exposed to a matching vulnerability. One security checking tool that has genuinely impressed me recently is CodeQL. If you’re using GitHub, you can run this as part of GitHub Advanced Security. Unlike those naïve tools, CodeQL seems to perform a real tracing analysis through the code, so its report doesn’t just say you have user-provided data being used dangerously, it shows you a complete, step-by-step path through the code that connects the input to the dangerous usage. This provides useful, actionable information to assess and fix real vulnerabilities, and it is inherently resistant to false positives. Presumably there is still a possibility of false negatives with this approach, particularly with more dynamic languages like Python where you could surely write code that is obfuscated enough to avoid detection by the tracing analysis. However, most of us don’t intentionally do that, and it’s still useful to find the rest of the issues even if the results aren’t perfect and 100% complete.
- varispeed 8mo agoBumping version of dependencies doesn't guarantee any improved safety as new versions can introduce security issues (otherwise we wouldn't have a need of patching old versions that used to be new).
- eru 8mo agoMaybe. But at least everyone being on the same (new) version makes things simpler, compared to everyone being on different random versions, of what ever used to be current when they were written.
- Chris_Newton 8mo agoIf you replace a dependency that has a known vulnerability with a different dependency that does not, surely that is objectively an improvement in at least that specific respect? Of course we can’t guarantee that it didn’t introduce some other problem as well, but not fixing known problems because of hypothetical unknown problems that might or might not exist doesn’t seem like a great strategy.
- jackfranklyn 8mo ago[flagged]
- solatic 8mo agoI sympathize with the author, and in principle I find myself nodding along with his prescriptions, but one of the benefits of Dependabot (and Renovate) are that they are language-agnostic. Depending on how many repositories, and how many languages, and upon whom the maintenance burden falls, there's a lot of value to be had. It may not really be feasible to add "the correct" CI workflows to every repository, and the alternative (nothing) inevitably ends up in repositories where dependencies have not been updated in years. It's good optimization advice, if you have the time, or suffer enough from the described pain points, to apply it.
- cedws 8mo agoI don’t know why the industry collectively accepted these security scanners (code + containers) that don’t even do the most basic of static analysis to see if the vulnerable code is reachable. Companies are breaking their backs trying to maintain a constant zero vulnerabilities in their container images when 99% of the CVEs don’t actually affect them anyway. The kicker is that updating the dependencies probably just introduces new CVEs to be discovered later down the line because most software does not backport fixes.
- eru 8mo ago> The kicker is that updating the dependencies probably just introduces new CVEs to be discovered later down the line because most software does not backport fixes. I don't understand how the second part of that sentence is connected to the first.
- cedws 8mo agoI could have written it more clearly. If you’re forced to upgrade dependencies to the latest version to get a patch, the upgrade likely contains new unrelated code that adds more CVEs. When fixes are backported you can get the patch knowing you aren’t introducing any new CVEs.
- hokkos 8mo agoMost CVE now are pure spam without value, all I get is dev dependencies affected by regex that could take too long, scanner should do a better job to differentiate between dependencies and dev dependencies.
- jgalt212 8mo agoThe lead example is about the (*Point).MultiScalarMult method (not a golang person so perhaps wrong terminology). Instead of, in addition to, updating all your dependencies, perhaps it would be better to emit monkey patches that turn unsafe methods into noops, or raise an exception if such methods are invoked. e.g "paste these lines at the beginning of main to ensure are you not impacted by CVE-2026-XXXX."
- 8bitme 8mo agoThe issue with not updating often enough is that if there is a zero day and you're far enough behind you will be forced to go through the pain of working out how to upgrade to the latest patched version where there may be a painful upgrade path in between
- maelito 8mo agoBetter : leave github for Codeberg.
- atypeoferror 8mo agoHow is this comment in any way relevant to the article or this discussion? Does Codeberg provide static analysis for CVE verification?
- clarabennett26 8mo ago[dead]
- 3form 8mo agoThis reminds me that the vulnerability scanner at my company flagged every version of pandas because it has some function in the API that allows to run some equivalent of eval. Thankfully I have the ability to issue a waiver with "does not apply".
- notepad0x90 8mo agoI really think the developer community needs to learn the age-old skill of ignoring things. Don't treat things like dependabot, PRs,stars, issues,etc.. as a metric or quantifier of how good of a job you're doing with your code. Forget that social-drama nonsense. I think the bigger problem is that Github is being treated as a quasi-social-media, and these things are being viewed as a "thumbs down" or "dislike" (and vice versa). Unless you have an SLA with someone, you don't have to meet any numbers, just do your best when you feel like it, and drive your project best way you think. Just don't be a dick to people about it, or react to these social-media metrics by lashing out against your users or supporters (not claiming that in this case!).
- andrewaylett 8mo agoI approve of Renovate's distinct recommendations for libraries vs applications. For a library, you really want the widest range of "allowed" dependencies, but for the library's test suite you want to pin specific versions. I wrote a tool[1] that helps me make sure (for the npm ecosystem) my dependency specifications aren't over-wide. For an application, you just want pinned specific dependencies. Renovate has a nice feature wherein it'll maintain transitive dependencies, so you can avoid the trap of only upgrading when forced to by more direct dependencies. The net result is that most version bumps for my library code only affect the test environment, so I'm happy allowing them through if the tests pass. For application code, too, my personal projects will merge version bumps and redeploy automatically -- I only need to review if something breaks. This matches the implicit behaviour I see from most teams anyway, who rely on "manual review" but only actually succeed in adding toil. My experience is that Renovate's lock file maintenance makes update a whole load safer than the common pattern of having ancient versions of most transitive dependencies then upgrading a thread of packages depended on by a newer version of a single dependency. 1: https://www.npmjs.com/package/downgrade-build https://www.npmjs.com/package/downgrade-build