this post was submitted on 11 Feb 2024
128 points (95.7% liked)
Programming
17534 readers
246 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
npm
downloads every dependency recursively. Ifa
depends ond (= 1.2.3)
andb
depends ond (= 1.2.4)
, then both versions ofd
get downloaded intoa
andb
's respectivenode_modules
.All other package managers I'm aware of resolve dependencies into a flat list then download, and you can only have one version of the same package on your system.
You mean npm duplicates even if the the two dependency versions are compatible?
That couldn't be, right? Otherwise, if you installed two packages that rely on different incompatible versions of another package, one of the two would break. Reading a bit they should check for "satisfiability", I found some really interesting things on the topic looking around:
By default yes, unless you explicity use the "peer dependency" system which isn't the default. The "default" naive implementation is for every package in your
node_modules
to have anode_modules
of its own, all the way down recursively. There are tricks nowdays to deduplicate packages with the exact same version, but not to automatically detect "compatible" versions and use those instead (in my experience nothing would work if that was the case, deleting package-lock.json causes way too many issues due to the... uh, let's call it "brave" approach of JS devs to stability).Correct. This is intended behavior which is solved in several ways:
1.2.3
should not break something built against1.1.2
. JS and NPM's cascade of stupid implementations bred a culture of "move fast and break things", but that's not the norm in any other commonly used ecosystemglibc6
isglibc6
, notglibc_string (1.2.3)
+glibc_memory (2.6.5)
+glibc_fs (1.5.3)
+glibc_stdio (1.9.2)
+glibc_threads (6.1.0)
+ ...Internally
glibc6
is a bunch of modules, but they get bundled into one package specifically to simplify dependency management.Not being able to install two versions of the same package sounds restrictive, but it's a HUGE security benefit:
glibc6 (1.2.3)
is vulnerable to CVE-2024-1, then updating toglibc6 (1.2.4)
secures your entire system at once. With NPM though, you have to either wait for every. single. dependency on that vulnerable package down your tree to recursively update, or patch those versions yourself (at your own risk because again, small version changes often break things since developers think that NPM's dependency model means they don't have to actually provide stability guarantees).Wow, awesome explanation! I think I understand now