Hunting for Gems: How Ruby's package management system evolved

Re:Hunting for Gems: How Ruby's package management system ev... by ryanbrunner on Monday September 30, 2024 @08:25AM (#41696361)

Do you mind sharing some details? This doesn't match my experiences at all really - while I think running into messes with NPM is sometimes a little overstated, the number of times I've needed to do something drastic like `rm -rf node_modules` is not insignificant and I've never had to do anything at all like that with Bundler.

The only problem I can really think of is working through issues when two gems require different irreconcilable versions of a library, and that's more of a fundamental ruby issue / design choice than a problem with bundler itself.

[ Parent | on HN ]

Re:Hunting for Gems: How Ruby's package management system ev... by qudat on Monday September 30, 2024 @09:43AM (#41696983)

The biggest issue was with using older versions of ruby or older versions of the bundler itself.

We had to pin our bundler to a specific version and it caused all sorts of issues when installing gems.

[ Parent | on HN ]

Re:Hunting for Gems: How Ruby's package management system ev... by hosh on Monday September 30, 2024 @09:57AM (#41697139)

I have had to use older versions of npm on unsupported nodejs. There was no pinning, or guard rails with upgrading. I have borked the entire npm install doing that because the later npm wanted to use newer syntax that was not backwards compatible.

What you and I describe is not a bundler or npm problem so much that the software we are working on requires an outdated version of ruby and nodejs.

I agree with the the other comment though — npm has more problems even when with the latest version. Like Nodejs, it is flawed by design.

[ Parent | on HN ]