Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Dependabot is now free (nimbleindustries.io)
158 points by colinbartlett on May 26, 2019 | hide | past | favorite | 25 comments


For anyone wanting this functionality directly in the editor and is working with npm / vs code i've found this extension to be great https://marketplace.visualstudio.com/items?itemName=pflanner...

( no affiliation just a happy user )


recent (4 days ago) discussion of the aquisition: https://news.ycombinator.com/item?id=19989631


I've been using Dependabot (for free) for my Rust projects for the last months, it really is nice.


Excellent marketing! I checked out the author's product, Statusgator, and signed up for a $30/mo plan. It aggregates statuspages of all the vendors we use, and pings our slack channel. Super useful!


What's the difference vs Greenkeeper?


Supported languages: Ruby, Python, JavaScript, PHP, .NET, Go, Elixir, Rust, Java, and Elm.


Greenkeeper seems to only support NPM, whereas Dependabot supports NPM, RubyGems, a bunch of other languages.


Ah I see, thank you!


https://renovatebot.com/ is open source and supports more dependency management systems


> "Microsoft, the richest public company in the world"

Not even the top 15 [1], they are 16th.

[1] https://www.forbes.com/global2000


I'm sure what they had heard was "highest valued" and drew some incorrect assumptions regarding what that means. But according to your link, they're not even highest there, beaten slightly by Apple.



I don’t understand why we need these tools when we use semver? The semver range should be flexible enough to handle the nonbreaking changes. You definitely don’t want a bot updating breaking changes of dependencies automatically, unless you like breaking things. That’s the kind of thing that should require manual intervention for.


As someone who has been using depenabot for my rust projects for about 6 months now, I appreciate having it attempt to upgrade past breaking changes. Not all breaking changes break everyone. When they do break, I appreciate knowing a new version is available for me to upgrade to so I don't fall behind. Probably the riskiest case is behavior-breaking (rather than API) and your tests don't happen to cover that case but dependabot helps by gathering changelist info that I first review.

This is on top of the benefits of upgrading pinned-but-compatible versions which someone else covered.


I like Dependabot because of the changelog and list of commits it includes in each pull request. It means that it's super easy for me to keep track of how the dependencies I use are changing.

There's been more than a few times that I've seen a new feature pop up in a changelog that ends up being super helpful for something I'm working on. And being able to track deprecation warnings as they're introduced means being able to gradually keep my usage of a library up to date, and avoiding painful upgrades later.


Unfortunately semvar isn’t law. Although people use it, it isn’t 100% reliable or implemented the same way every time. There isn’t an agreed upon semvar code analysis tool.

I personally think a standardized method of providing or writing change logs is the next iteration of semvar.

Currently it’s a hot mess of using a changelog file, release notes, private website, all in unstructured text format, even if generated from commits.


Typically you lock in specific revisions of your dependencies until the next time you run your dependency management tool, at which point it is free to bring in nonbreaking changes.

You don't want stuff changing of its own accord without a corresponding commit in your own repo. Especially not on a per-installation basis. Sometimes people get SemVer wrong. Or you may be bit by the bug that caused a patch release on one machine, and want to reproduce the issue on another.

But the downside of pinning versions is that you don't get the patch release in dependency A until you go to update/install unrelated dependency B. For a mature project, that could be never, or only by giant leaps every few months or years. Tools like this keep your version locks consistently up to date.


> I don’t understand why we need these tools when we use semver?

This sounds like "why do we need cooks when we have cooking books".

Semver is a policy/idea. It doesn't actually do anything. Dependabot lets you know about updates and tries to do them for you.


Whenever you see a manual task, think "opportunity to automate". Just need to think it through. In this case, if you have great tests and automated CI process, then dependabot might be a good fit.


I wish we could do away with the clickbait nonsense headline editorializing.


Anyone who'll say something is amazing without saying what it is is trying to game you.


Your insight is amazing


Setup and installation is simple: a quick sign up with GitHub OAuth was all that was required, along with a grant to read and write code in our repositories.

Why does it need permissions to read and write code? If it's a public repository, anyone can read. It shouldn't be modifying code. At best it should be submitting patch requests.

Giving Microsoft write permission on open source code is dangerous. They might decide that they need to inject "telemetry". As they've done to non-Microsoft applications on Windows.


When it creates a PR it creates a branch which requires write. Maybe it could offer the option to create a fork instead, but that would add awkwardness and friction just to satisfy a very small set of overly paranoid users. If you don't trust GitHub not to modify your code why are you using GitHub as a host in the first place.


It creates branches in your repository that are used to make pull requests. Totally normal.

The part of your post about telemetry is FUD and probably why you are being downvoted. These are pull requests you can review before merging.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: