[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Lots and lots of tiny node.js packages

Russ Allbery <rra@debian.org> writes:

>> The web ecosystem is still changing rapidly, with WebAssembly coming
>> soon, so probably things are going to look very different for the
>> Debian buster development cycle.
> Indeed.
> I do think the Node community takes this too far, with way too many
> micropackages that should just be part of the standard library.  But,
> well, it works for them, and it's not a totally unreasonable way to handle
> things.  I think Debian should find ways to stay flexible and adjust and
> incorporate those sorts of philosophies about the reusable unit of
> code.

As an interested observer, this flood of packages certainly is a bit
surprising (although it is very nice to see the underlying problem of
missing build tools being addressed).

However, having seen the case of node-os-homedir, it strikes me that
there is one very good reason to package things individually.

It focuses our disdain where it is deserved.

If this were in a combined package, and if the broken code was only
spotted after passing NEW, then it would be much more effort to eject
it.  It would almost certainly be argued, as you'll see here:


that the code should never be reached in the real world, so nothing to
worry about. That however glosses over the fact that we have downstreams
doing many bizarre things, and that someone might manage to reach the
hopeless code, and thus suffer foreseeable bugs.

As it is, we can just say "no thanks" to that specific package, with the
result that the packages that depend upon os-homedir get patched to use
something newer (if they're to be packaged), to the benefit of the whole
node.js community.

On the other hand, I suspect that a lot of this code is really not fit
to be packaged yet ... or at least not for stable.  Take a look at:


This a trivial bit of code, which will make those of us not in the
node.js community boggle, but let's forget about that for a moment.

Let's say that it had been packaged in May this year, at version 2.0.1
and that would make it's way into Stretch, and thus be preserved in
aspic until the end of the LTS support.

In June, version 3.0.0 was released, which reverses the order of the two
parameters.  I presume that much of the software that uses that function
will rapidly switch to the new ordering, and would have thus found our
2.0.1 package worse than useless.

This is not really criticism of the 'repeating' library itself, but just
an instance where a slight change of timing seems likely to have
resulted in poor outcomes, if we let this sort of software into stable.

That said, the decision to swap the parameters is apparently justified
by the fact that 99% of the usage of this function is to repeat an empty


which makes me realise that I really have no clue whatsoever what they
think they are doing in the land of node.js

Cheers, Phil.
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

Attachment: signature.asc
Description: PGP signature

Reply to: