npm fund and micropackages

[corwin-of-amber]

I highly value npm fund and its potential impact on open-source development. That is a neat thing to solidify in community-driven code, because today, code is like regulation. The functionality of software tools greatly affects emerging norms.

So I am wondering about this issue. Right now, my npm fund report looks like this.

39 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
% npm fund
toxin@0.1.0
├── https://github.com/sponsors/feross
│   └── buffer@5.7.1
├── https://github.com/chalk/ansi-styles?sponsor=1
│   └── ansi-styles@4.3.0
├── https://github.com/sponsors/sindresorhus
│   └── p-limit@2.3.0
└── https://github.com/sponsors/ljharb
    └── is-nan@1.3.2, call-bind@1.0.2, get-intrinsic@1.1.1, has-symbols@1.0.2, object-is@1.1.5, is-arg
uments@1.1.1, has-tostringtag@1.0.0, is-generator-function@1.0.10, is-typed-array@1.1.8, available-typ
ed-arrays@1.0.5, es-abstract@1.19.1, es-to-primitive@1.2.1, is-date-object@1.0.5, is-symbol@1.0.4, get
-symbol-description@1.0.0, is-callable@1.2.4, is-negative-zero@2.0.1, is-regex@1.1.4, is-shared-array-
buffer@1.0.1, is-string@1.0.7, is-weakref@1.0.1, object-inspect@1.11.0, object.assign@4.1.2, string.pr
ototype.trimend@1.0.4, string.prototype.trimstart@1.0.4, unbox-primitive@1.0.1, has-bigints@1.0.1, whi
ch-boxed-primitive@1.0.2, is-bigint@1.0.4, is-boolean-object@1.1.2, is-number-object@1.0.6, side-chann
el@1.0.4, which-typed-array@1.1.7

This is really not such a big deal. But it gives the false impression that I am heavily dependent upon the work of a single author. In fact, these 36 packages are all left-pad-like. They are near trivial, and while these packages are downloaded in staggering numbers, due to transitive dependencies, the ingenuity encased in them is minimal. The large number of packages is due to the author's decision to split their code into hundreds of micro-packages. I feel that would skew developers' incentives, as it penalizes those who try to follow "good" design principles, such as grouping related functionality into modules.

Suggestions? First, I thought perhaps show something like this:

39 packages by 4 authors are looking for funding

(along the lines of some of the output from npm audit).

Also, perhaps (don't shoot me) limit the number of packages listed for a single author? E.g.

% npm fund
toxin@0.1.0
├── https://github.com/sponsors/feross
│   └── buffer@5.7.1
├── https://github.com/chalk/ansi-styles?sponsor=1
│   └── ansi-styles@4.3.0
├── https://github.com/sponsors/sindresorhus
│   └── p-limit@2.3.0
└── https://github.com/sponsors/ljharb
    └── is-nan@1.3.2, call-bind@1.0.2, get-intrinsic@1.1.1, has-symbols@1.0.2, object-is@1.1.5,
        + 31 others

I have no idea how NPM would choose which ones to show. The ones actually closest to the root package in the dependency tree? The most recent ones published? I guess a rule that is easy to implement (and is therefore prone to cause fewer faults) is better, but whichever rule is chosen, it would be better than the current behavior, which, most frankly, makes the output of npm fund for nearly any project look a bit ridiculous.

I am just afraid that users are going to get into the habit of routinely ignoring npm fund, if it stays like that. That would benefit none of the developers in the community.

[ljharb]

left-pad like packages are NOT trivial, and in fact, every single left-pad one-liner hot take on Reddit or HN during that incident had subtle bugs in it. It's actually hard to get these things right consistently, and that's the value of having these packages in the ecosystem. I would argue that "good" design principles include splitting things up into many small packages.

npm shows every single package that defines funding information by default, and shouldn't apply any subjective rules to what it shows.