> AFAIK most package managers are essentially a .tar with a checksum.

Yes, basically. By the same way of thinking npm is essentially a variant of
wget and shell scripts interpreter for running build rules. It's the details
of the implementation and what use techniques are most obvious and convenient
that make the tool.

> Eg. how does each project declare which RPMs? How are these RPMs getting created, by hand and one per package?

For daemons, command line tools, and libraries -- usually one package per
repository (sometimes several packages built from a single build rules set, if
it makes sense to install part of the project as a standalone thing).

Websites, since it's a custom to put a shitload of mostly trivial dependencies
that form a fractal, get two packages: the actual code and all dependencies
bundled together.

Note that all of the packages are not built from source code (and `npm
install' or `pip install') directly, but they go through a source package
(e.g. SRPM), which is especially important for dependencies. This way you
always have a way to rebuild the dependencies in exactly the same versions
(e.g. after patching one of them), you have an obvious place to store the
dependencies (i.e. along with binary packages; package repositories support
serving both) without growing your source repository unnecessarily, and you
have an obvious place to apply patches to external dependencies.

The only downside is that you'll need to write a downloader script, because
language-specific module managers (pip, npm, gem) usually assume their user is
too stupid to run as two commands two logically separate steps of fetching and
building the packages.

> I've literally never heard of anyone using rpms for nodeJS dependencies, and I am intrigued.

Well, yes, that's because Node.JS crowd doesn't have the habit of learning
what other IT fields were using successfully for decades.

> Or are you suggesting each dependency gets wrapped into an rpm? Because that sounds time consuming & doesn't seem like it provides any benefit [it'd be just swapping npm for rpm, it sounds like?].

If the repository was handled the same way as the rest of the code, then yes,
there's little benefit. If it was handled the way as the rest of the binary
packages are in the distribution, you get for each binary package a source
package and uniform build process, so you can rebuild each package every time
you need to, and there is good tooling for automating building the packages.

> AFAIK, RPM & NPM were made to solve totally different problems.

One was created to make installing and deploying code easy, while the other
was created to make installing and deploying code easy. Yes, totally different
problems.

> Trying to use NPM to manage linux packages or using RPM to manage javascript packages honestly sounds like a nightmare, going against the grain.

Actually only the former of these is going against the grain. The latter, on
the other hand, requires learning tooling that hasn't substantially changed in
over a decade and comes from different field, so it's unsexy and uninteresting
for most of the programmers.

> RPM was made for linux packages, not frontend web development.

And how exactly differs deploying some code to a directory and running some
daemons between software that comes from a distribution and software that you
have written yourself for running a website?