There's no reason to commit your dependencies if your intent is security. Just use the lock file. The packages won't change on npm and you'll always get the same version for all sub-dependencies.
The ones who do are focused on caching private npm servers like verdaccio.
Personally I do not understand why Java libraries which are binary blobs are not targeted more often.
Java libraries are JAR -> Java Archives. You can unzip them and there is JVM bytecode inside which can be decompiled. Not really binary blobs.
Until they decide to stop hosting old versions you need, because reasons.
Though I agree, over reliance on just npm can be a bad thing (the 2016 issue over kik)
You actually see the diff on dependencies on updates. Vendoring is done in the Go world. Together with `yarn autoclean` it can be reasonable.
Perhaps, but building from a controlled body of code fully under your own control also has some big advantages over the typical package management and development culture in the JS world, which I think it's fair to say has been a pretty good representation of how not to do robust, professional software development for years.
This article is about the latest high-profile mess with event-stream, but it follows years of interrupted work because NPM was down again, several generations of tools that couldn't meet basic requirements like reproducible builds, excessive dependence on near-trivial packages like left-pad, and of course the overall problem that managing thousands of such dependencies is basically an impossible problem and inevitably leads to problems with trust, reliability, licensing and legal matters, and so on.
Distribution maintainers, developers and system engineers have to either unvendorize everything or go through all vendorized dependencies every time a vulnerability comes out and patch them.
Most live systems cannot receive a full upgrade every time a patch is published.
Use dynamic linking on languages that support it and don't vendorize things.