On Tue, 21 Oct 2014 10:38:14 +0200, Sönke Ludwig wrote:

Am 20.10.2014 18:12, schrieb Angst:

(...)

Don't underestimate the usefulness of trivial/small pieces of code!

Take the grunt plugins:
http://gruntjs.com/plugins

You could classify a lot of these node modules as trivial: actual code (excluding tests) being around 100 lines. But they are well tested and without them grunt would not be possible.

Standing on tiny shoulders is still nice ;)

Sure, but it also comes at a cost:

Let me reply from my limited experience with npm front-end web dev.

  • Selecting the right package may cost more time than writing the code

itself if there are many alternatives

"Search by popularity/starred"-on-by-default seems to fix this problem for grunt.
Become the most used module or die in the long-tail.

  • It increases the chance for unintended license violations when

different licenses are involved and a project has dozens of dependencies

There is a module for that:
https://www.npmjs.org/package/license-checker

But on a whole people tend to not really care and expect everything to be MIT or something alike.

  • It increases the chance for version conflicts when e.g.

"trivial-pack-a" depends on the same dependency "pack-c" as
"trivial-pack-b" (maybe indirectly), but accepts a different
version(range) for that package

Npm solves this by making all dependencies local:
project/nodemodules/module/nodemodules/depmodule/nodemodules/depdepmodule/...
or, in your case:
project/nodemodules/trivial-pack-a/nodemodules/pack-c(0.1)
project/nodemodules/trivial-pack-b/nodemodules/pack-c(0.2)

  • It increases the maintenance friction (e.g. you have to wait for all

dependencies to fix compilation on the latest DMD version and you may)

I am not sure how much of a problem this is for npm.
Personally I haven't had any such problems but I haven't been using npm that long either.
Could be a real problem for D(UB).

So it's a nice thing to have in principle, especially for rapid
prototyping, but I'd definitely rather prefer a library that manages a
bunch of trivialities under one umbrella to avoid the above issues.
There are always exceptions of course, though!

If search-by-popularity would be on by default and most people agree with your mindset, then all the trivial modules would die in the long-tail. But first, lets give the trivial modules and giants a place to have a real fight ;)

At least with the new "dub.selections.json" feature, DUB should be well
prepared for managing large dependency hierarchies.