Comment by ksenzee
11 years ago
You can't escape problems by bundling specific library versions. You just get a different set of problems. When you require a specific version of a library, you're making your code incompatible with anything that requires a higher or lower version of that library. You're also assuming there will never be a security fix that requires you to update your dependency.
...you're making your code incompatible with anything that requires a higher or lower version of that library.
Actually that's not correct when using node/npm (or anything else in the ecosystem like browserify). That is one of the impressive things about this platform: any number of different versions of the same module can be required by the same app. It would be nuts to do that in your own code, but as long as the craziness is in your dependencies it really doesn't matter.
And that kind of works in a dynamic language. You could make it work in a statically-typed language, but then the problems will become more apparent. If X depends on Y and Z1 and Y depends on Z2, and Y exposes an object created by Z2 in its public API, the X developers might look at the Y api docs and try to call Z1 functions on that Z2 object! Worst of all, it might very well work in the normal cases, and the issue might not be noticed until it's in production.
Using multiple versions of the same library is code smell. It's a stability issue, a security issue, a complexity-breeder, and an absolute nightmare for packagers.
And npm allows it to happen silently.
Yeah I'm sure it sucks for distro packagers. Why are they using npm, though? It's not designed for their use case.
Actually though you're just talking about some bugs in X, or possibly some design flaws in Y. Passing [EDIT, because bare objects are fine:] class instances around like that is the real code smell. So much coupling, so little cohesion. We call them "modules" because we like modularity.
4 replies →
...and now you can have all the bugs introduced in all the versions of the library! Yay!
Or you could have all the bugs introduced in everyone's hand-rolled implementations of it. I'll take multiple versions of the library instead. It's much easier to track issues and submit patches to update their dependencies later.
1 reply →
More importantly, if you only use a specific version of a library, you're opting out of literally every one of the advantages of micro-libraries that people claim they offer. Tying yourself to a single version is the same as copy-pasting the code right into your project, except it doesn't force you to look at the code and vet it.
And writing the code yourself instead of taking on a dependency solves none of these problems. Your code becomes incompatible with anything, because you wrote it yourself. And you are responsible for making any security fixes yourself.
You just get a different set of problems. When you require a specific version of a library, you're making your code incompatible with anything that requires a higher or lower version of that library. You're also assuming there will never be a security fix that requires you to update your dependency.
If there is a security fix, you should bump your dependency by hand, the other problems that you pointed out do not exist in Node (and it's about time they disappear in Java)