> It honestly does sound like a novel idea but untenable unless the whole nodeJS community changes.

The thing is, it's not novel by any stretch. Sysadmins use this method for
almost twenty years already. About the only novel part (i.e. I didn't read it
anywhere but thought up myself) is the binary package that contains all the
modules required by web application, and even this I don't believe I was the
first person to do.

And it's not untenable. It's not a method for distributing code to other
programmers, it's a deployment method. Everybody can use it on their own
method, without looking at Node.JS community.

> It also doesn't account for different team members running different OSs.

It's a deployment method. Everybody in the team is free to make as big mess
with any other tool as they like, as long as the end thing builds properly for
production system, and you can easily provide everybody a virtual machine for
checking if build process still works.

> npm/yarn are platform independent, rpm is not.

Not quite. RPM does run on different platforms (OpenPKG proved practicality of
this long time ago), and even then, you don't want a build from macOS or from
desktop Fedora running on Debian in the production. Binary packages show up in
the picture not in the process of writing the code, but in deployment.

> like I said, npm & rpm solve totally different problems. One is made for interactively installing linux binary packages on a specific distro, and requires config management like Ansible to orchestrate in an automated fashion.

Not quite, for both of the claims. DPKG and RPM started as such, but they
are designed to allow to anchor the installation root in an arbitrary
directory. And managing configuration? That's not DPKG or RPM thing, and you
get exactly the same with any other deployment method (unless you do the
brain-dead thing and ship the configuration hardcoded in the deployed
artifact).

> Whereas npm/yarn is made for platform independence & copying javascript files into a directory, not system binaries, and has a manifest which makes automated builds easier.

This doesn't differ even a bit from how DPKG and RPM operate. The only
difference is that npm and Yarn are written in JavaScript, while DPKG and RPM
are in C/C++.

> I think one of the biggest differences that affects reliability is npm uses github repos, which each author can change, or delete without moderation.

And this is where building binary packages from source packages comes into the
picture. Debian, Ubuntu, Fedora, or CentOS can rebuild their whole
repositories even without the original source tarballs available in their
official place (it could have changed, it could have expired, project could
have been shut down, or for any number of other reasons). Full source is
kept in the very same package repository as binary packages, along with build
scripts, patches, and all the other things necessary for build.

> AFAIK redhat moderates their repository & does extra leg work to make sure things work together.

Curation of the upstream OS has nothing to do with using your own RPM or DEB
repository for deploying code to your own infrastructure.

> Its probably also easier to keep things stable when you only target 1 platform.

Oh, but for production you are targeting just one platform. I'm yet to hear
about anybody who deploys their own software to servers running more than one
OS flavour. Usually production for in-house developed web software is quite
homogenic, all runs under Ubuntu or all runs under Debian or all runs under
CentOS.