Hacker News Reader

Comment by hosh | Hacker News Reader

It’s even worse when npm install modifies the package lock file.

It also doesn’t understand how to get packages from a git source.

From a release engineering perspective, this drives me batty.

i’ve said before that it’s like the npm people have made the worst possible design choice whenever asked for a decision. it’s insane how bad it is compared to bundler or comparable package management tools.

No, I strongly disagree. Npm may have some weird ergonomics and defaults, but as a dependency manager it is first class. Before npm, almost all dependency managers suffered from the diamond dependency problem. Npm pioneered allowing multiple versions of packages to be simultaneously installed without having to chase down conflicting dependencies as long as the package involved is not a major framework (i.e. peer dependency). For example you can’t (or at least strongly discouraged to) have react v15 and react v20 in the same project, but you can have leftpad v1 and leftpad v3 in the same project. You cannot do this in most other languages like Ruby Python Dart C++ etc. (Java has a similar but half baked concept called shading which requires a separate plugin) Go and Rust followed what npm pioneered, allowing multiple conflicting dependencies too, saving countless hours of developer time. Rust goes as far as supporting linking against code from different language versions. Without npm, Cargo would be doing NP class dependency searches and Rust developers would be wasting forking old upstream repos to bring them up to date. Not everybody has the engineering resources of google to build everything in house and keep every single dependency in sync through a massive monorepo and test suite.

In the npm-style dependency managers, generally speaking, you don’t really get dependency conflicts unless it’s a large overarching peer dependency or something like global singleton e.g. a GPU driver. Regardless of your thoughts on npm or having a massive number of tiny dependencies, you can’t deny npm dragged the dependency management field into the 21st century and forced it to scale.

Allowing multiple versions of a library to run simultaneously is a design decision - there are definitely shortfalls to allowing this (increased code size, a relative nightmare to audit, increased tendency towards downstream dependencies opening vulnerability potential). Culturally with bundler it tends not to be an issue since the inability to run multiple versions of packages tends to reduce the number of secondary dependencies to only pretty core libraries, and encourages permissive version requirements for gems.

> You cannot do this in most other languages like Ruby Python Dart C++ etc.

for good reason. I strongly disagree that what you say is a good thing. you are describing a failure of the javascript ecosystem as a whole where pulling in a package for some trivial(leftpad) task is seen as a good thing and that having incompatible versions of them being able to be installed at the same time is a good thing instead of an indictment on the system. I stand by my statement that they have made the wrong decision at ever step.

This is such a wild take. I’m constantly running into issues with bundler and literally never have issues with npm or yarn. Not to mention the amount of innovation happening within that world with module resolution algorithms.

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.

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.

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.

As I understand it, the idea is that npm install is what's used during development, while npm ci/clean-install is what you use for deployments and your CI system.

It makes the pretty heavy assumption that a developer will always be able to bugfix the version differences.

But then that means the version you use to develop is not necessarily the version you end up in production. Or that the version one developer uses is not the same version another developer on the same team uses.

> It also doesn’t understand how to get packages from a git source.

Not sure what you mean.

https://bundler.io/guides/git.html

He's talking about npm

You have been able to do that for a few years now, e.g.: `npm i https://github.com/user_name/node_project_name`

...or with `npm i git+ssh:...`, and npm will git clone it locally, as long as it has a `package.json`

You can install a certain commit, or even from a Gist!

Reply on news.ycombinator.com