2 ms·

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 co

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.

NathanKP 11y ago
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.
- janl 11y ago
  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 :)
- daleharvey 11y ago
  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.
janl 11y ago
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).
LukeB_UK 11y ago
You want this: npm install --save --save-exact
- daleharvey 11y ago
  --save-exact doesnt deal with any nested dependencies, we do use it for top level deps though.

NathanKP 11y ago

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.

janl 11y ago
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 :)
daleharvey 11y ago
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.

janl 11y ago

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).

LukeB_UK 11y ago

You want this: npm install --save --save-exact

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