Greenkeeper: Always up-to-date npm dependencies | Hacker News Reader

Greenkeeper: Always up-to-date npm dependencies

greenkeeper.io

52 pointsingve21 comments

Here's my 2 cents coming from experience with Rubygems (and my minimal experience with Node).

You simply cannot auto upgrade dependencies. Period. On an application running in production with development spanning over a couple of months this will break a lot of stuff.

For that to happen, all package developers have to follow semantic versioning and make sure they never break API with minor updates, but that's hard to achieve when you have so many developers.

Updating packages is unfortunately a manual process that you have to go through, you have to pin, upgrade, run tests, rinse and repeat.

I would love a notification when an upgrade is available, whenever a package is released, that'd be good, but still, the upgrade process on my side would be manual.

Heya, you summed up the problem perfectly and we are not trying to be all clever solving this unsolvable riddle.

All Greenkeeper does is send you a Pull Request, which then runs your test. Only when you as the maintainer are satisfied this works, you get to merge the PR.

We have another project https://github.com/semantic-release/semantic-release that you can use to make sure your project leaves semver to computers and keeps humans out of the process, because they tend to screw this up.

With both Greenkeeper and semantic-release, we hope to get npm into shape that we, one day, can do more automated updates and it’s gonna be a long road, but we’ll have to start somewhere.

For now, Greenkeeper takes a lot of the chores out of the process you described to well in your comment.

"All Greenkeeper does is send you a Pull Request, which then runs your test. Only when you as the maintainer are satisfied this works, you get to merge the PR."

This is actually golden. When you do this for Rubygems. I will be the first paying customer.

Greenkeeper dev here, Another fun thing we can do with this is, say Node 5.0 comes out, we send a PR for everybody’s .travis.yml, to also test against 5.0 and see if a package is still compatible. And all that with without the maintainers having to install the new Node version, or fearing they screw up the dev environment.

Let computers do the chores for us :)

Use next-updater - tested dependencies update for projects in bulk. Npm publish, github tag, push, etc. Flexible ranges (major, minor, patch), etc. You control everything. https://github.com/bahmutov/next-updater built on top of next-update https://github.com/bahmutov/next-update

Great idea - I wish this existed for Ruby gems. Currently we use Gemnasium to keep track of our dependencies and have a manual process to:

- check Gemnasium

- bump the gem locally and push to branch to GitHub

- find the changelog for the change (or a diff link) and paste create a PR with that as the description

- merge and deploy if our test pass and the changelog looks OK

Everything except the final step should definitely be automated. I can totally see how doing the same across many repos and sharing aggregated information could make the final step a lot easier, too.

Psyched to see you guys expand.

Actually, Gemnasium now has an auto update feature.

Question to the devs: you mentioned [0] that you eventually hope to auto-upgrade peoples' app code for package BC breaks. My initial thought was that this would be the logical conclusion for a service like this, but my next thought was realizing how much magic it would take.

But, apparently you are magical. ;-) What can you tell us about your planned approach to automating this? Seems like a massive undertaking.

[0] https://twitter.com/janl/status/647406012018872320

No plans yet, just marvelling at the opportunities :)

This has been my primary annoyance working in node.js, dependencies automatically updating and breaking our code.

So far everyone has convinced me away from committing node_modules to the repo or doing an npm shrinkwrap, but I would love seeing a future with more people pinning dependencies and using this to update.

If you have sufficient test coverage and a proper merging and deployment flow then package upgrades that break your code will be caught, and you'll have a chance to adjust your code in response to the package changes.

The one minor issue I've still had with automatic dependency upgrades is the extremely rare case where a package maintainer actually pushes a broken package version. In those cases our tests catch it but I have to temporarily pin that specific package on the previous version until the maintainer is able to deprecate the broken package version and push a new one.

The problem here is with your downstream users, an `npm install` two months after your release might install a broken sep for your end user and create a support request for you. This is a bad situation to be in if you are doing this for Open Source projects on volunteer time :)

I am talking about the situation where our tests catch the breakage, however rebasing does not work in this situation, with deeply nested dependencies it can be quite hard to figure out which update broke our library.

Our hope with Greenkeeper is to get all of npm on it, so we all get to benefit from it.

In addition, we could do things like pro-active issue-opening. Say Underscore releases a new version and Ember uses it, gets a Greenkeeper dependency bump, and we see its Travis fails, we can open an issue on Underscore to say they broke Ember (all opt-in, of course).

You want this:

  npm install --save --save-exact

--save-exact doesnt deal with any nested dependencies, we do use it for top level deps though.

Hey, another Greenkeeper dev here. I made a very short 3min demo video so you can see how it all works: https://www.youtube.com/watch?v=XbQvxCLkBbw

We’re super happy for any feedback :)

Very cool. Any plans to support other languages/packages management systems?

Not at this point, we are aiming at deep integration with the npm/GitHub ecosystem. Happy to talk to others on how to do it, though, just get in touch: hi@greenkeeper.io

A bit too expensive - twice the GitHub pricing for start packages.

it's free for open source though. And provides more than server space for your repos...

Reply on news.ycombinator.com