npm package malware is also a technology problem. Deps should be built at install time, on-host from original inspectable sources but npm practice is to build at package publish time so it runs everywhere w/out a build step. How badly you want JS to "not" be a compiled language!
So you have everyone turning their "JS" into *actual* JavaScript in a way that obscures the original intent, allowing things like the recent vulnerability to slip in easily. To fix this you need a completely different package management philosophy centered around.. Builds!
You can't easily take existing npm packages and run their publish steps at install time on your host, for many many reasons - these transpilation/minification toolchains are huge because they *could* be - they were just publish time dependencies that were dropped once published.
If you thought node_modules were a black hole now, just wait until you also install all the "devDependencies" of all your transitive dependencies. That's if the constraint solver doesn't just completely give up causing pkg version duplication that result in runtime failures/bugs.
And in addition to installing those dependencies every consumer (at install time) would also need to run those build steps on their host and those are typically slower because they always could be - they were only run once at publish time. Until now!
And even *if* you manage to get this far, you'll deal with npm's weird build caching bugs that occur because npm wasn't meant to be used for building things on the install host.
To really address the npm package build/publish problem at its core, @andreypopp and crew have been working on esy.sh - a package.json workflow for Native @reasonml/OCaml that is centered arounds reproducible, cacheable, from-source, builds!
