The only behavioral difference I see is that with most other package tools, installing a dependency pins the specific version of the dependency you installed.
So why does NPM instead pin "any version at least this, or greater"?
Feels like a decision that was made when the tooling was young to help improve reliability that has since created this nightmare. Is Yarn better about it?
I don’t think it’s uniquely bad. For example, Python’s story is just as bad.
The Java world is the best i know of but even relatively modern stacks like Rust are still making the same errors long-solved in the java world.
For example, nothing stops me publishing a google-grpc crate today (first come first served on names and that name’s not taken and i don’t need to prove ownership of my domain like in the java world).
C# and nuget is a blind spot for me so I don’t know. Go gets it right arguably even better than Java. Deno borrows the same decentralised idea.
The whole situation is a stack of cards right now though. I’m genuinely surprised we haven’t seen more specific targeting of high value maintainers. Github is arguably ahead of the curve here a little bit (e.g. the ability to flag and act on unsigned commits).
I'm not sure that it is. I think it's a numbers game. I've read* that npm is the largest repository in the world. More actors means more good and bad actors.
* Taken from this link. Old article and I'm not sure what the original data source is: https://www.linux.com/news/state-union-npm/
It's the classical situation of the framework having defaults that end up being actively hostile to developer success. These Primrose Path situations get under my skin like few things do.
It doesn't, it follows semver and you can pin to point, minor, major, etc versions depending on your package.json