While I understand the benefits the author presented about having many small packages, I still wonder what kind of effect this has on resolving overlapping dependencies.
EX: I have package X that depends on A, B, and C and I decide to use package Y that depends on C, D, and E.
D and E may very well be an alternative implementation of A and B, given the large number of packages and a finite solution space.
On the one hand it's easy to think that the best libraries for a particular task will rise to the top, but as a newer node dev, having to reinvent so many wheels for use in node is not very attractive. (However, this is almost counteracted by having to only write in one language).
I think the modules which tackle very common functionality do naturally rise to the top, and end up being well-maintained and fairly standard throughout the community. A good example is mikael's request (https://github.com/mikeal/request) which I suppose is a urllib2 equivalent.
Modules like this are constantly referenced in other modules, and in tutorials etc. By scrolling down this list (https://npmjs.org/browse/depended) you can get a sense of which modules now form the community curated 'standard library' for node - if you were a new node dev looking for a very common piece of functionality for your project, this might be a good place to start looking.
That's actually a solved problem (in node.js at least). npm builds a node_modules tree where each package gets its own copies (with the correct versions) of its dependents. Gone are the days when people took on dependency hell for a few MB of diskspace.
EX: I have package X that depends on A, B, and C and I decide to use package Y that depends on C, D, and E.
D and E may very well be an alternative implementation of A and B, given the large number of packages and a finite solution space.
On the one hand it's easy to think that the best libraries for a particular task will rise to the top, but as a newer node dev, having to reinvent so many wheels for use in node is not very attractive. (However, this is almost counteracted by having to only write in one language).