6 ms·
It's not as bad as the article makes it sound. Package managers like npm5/yarn and Cargo have lock files that pin exact versions by default, for all dependenci
by pornel 9y ago
It's not as bad as the article makes it sound.
Package managers like npm5/yarn and Cargo have lock files that pin exact versions by default, for all dependencies, recursively. If you keep that file (commit it), your project will be immune to unexpected breaking updates.
Semver-based package managers also don't just naively always upgrade to the very latest version like the article suggests. The default behavior is to limit upgrades to semver-compatible versions. There are tools like greenkeeper which use your project's unit test to try out packages before upgrading, adding extra level of assurance.
While none of this is a perfect guarantee, it's IMHO working well enough.
- kilroy123 9y agoAgreed, but we've noticed some weird issues at work lately. When someone is on an older version of npm or on a different system, (linux / mac os) things get fucky with the lock file. The lock file is changed and they just blindly commit it. So kinks still need to be ironed out with npm, IMO.
- sambe 9y agoBugs exist. That isn’t a design problem. Neither is carelessness. I don’t think either are the thrust of the article.
- akkartik 9y agoI wasn't aware of greenkeeper, thanks. Can you give some examples of "Semver-based package managers"? I'm curious what you think of the two posts I was basing mine on: "Spec-ulation" by Rich Hickey: https://www.youtube.com/watch?v=oyLBGkS5ICk https://www.youtube.com/watch?v=oyLBGkS5ICk "Volatile Software" by Steve Losh: http://stevelosh.com/blog/2012/04/volatile-software http://stevelosh.com/blog/2012/04/volatile-software I think there may partly be a "universes colliding" effect here, and partly just the future being non-uniformly distributed.
- hobofan 9y agoBased on pornels' example, "Semver-based package managers" are most modern ones (npm, bundler, cargo) that have the concept of Semver embedded in the version constraints for dependencies. E.g. the tilde (~) and caret (^) operators in npm[0] allow you to specify version constraints on dependencies, that allow them to be resolved/pinned to higher minor/patch versions of that package, but not to a higher major version since that will by the Semver definition contain breaking changes and those might impact your project. [0]: https://docs.npmjs.com/misc/semver#tilde-ranges-123-12-1 https://docs.npmjs.com/misc/semver#tilde-ranges-123-12-1
- akkartik 9y agoIf that's true then Rich Hickey has refuted this approach to my mind. See my link in OP. I also mentioned npm and bundler in OP. This is precisely the approach I'm against. It's good locally, but deteriorates the eco-system at large when everyone follows it.
- masklinn 9y ago> There are tools like greenkeeper which use your project's unit test to try out packages before upgrading, adding extra level of assurance. Some communities have also started doing the reverse, where as a library you can get all your users's tests to run to check that you have not broken something they were using.
- catern 9y agoWhat communities/projects do this?
- masklinn 9y agoI know that that happens for the Rust compiler, possibly some libraries as well. I don't know that it's systematic but I do know that they regularly leverage Cargo to find out major dependencies/users and run those against pending changes.