❦ 13 juillet 2014 11:34 +0200, Jeroen Dekkers <jeroen@dekkers.ch> :
>> > And I've got to ask: for the couple of trivial examples that Frederick
>> > pointed out - why on earth do these even exist as libraries instead of
>> > being inlined wherever they're needed?
>>
>> Because, in node, a library is cheap and the functionality get unit
>> tested. That's why there are so many dependencies in this ecosystem.
>
> You have all the extra metadata, extra git repository, extra
> dependency tracking, etc. no matter how 'cheap' a library is.
It still makes the library cheap. Those extra stuff are why the library
is done in the first place. They allow people to find simple stuff
without reimplementing it (usually with additional bugs).
That's exacerbated by the fact that the standard library is inexistent
with javascript and that the one that comes with node is quite small.
Looking at the stats of this trivial library:
https://www.npmjs.org/package/ms
I see it is quite popular and used by many (101) projects. That's
projects finding the library useful enough to not inline it.
> And as far as I understand npm (correct me if I'm wrong, I don't use
> npm very often), it will install dependencies in a nested way, so if
> app1 use library1 and library2, and both those libraries use
> tinylibrary1, tinylibrary2 and tinylibrary3, then those 3 tiny
> libraries will be installed both under library1 and library2. I
> wouldn't really call that cheap.
You are right. That's their way to not have to really manage
versioning. But that's the same cost when inlining. And that's
irrelevant in the Debian case since we don't nest.
--
Treat end of file conditions in a uniform manner.
- The Elements of Programming Style (Kernighan & Plauger)
Attachment:
signature.asc
Description: PGP signature