4 ms·
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 chanc
by 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 agoThe 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 agoI 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.