Sure. They don't include "node_modules" directory in their .gitignore file.

So any third party code changes end up in git commits and are easily visible and reviweable.

So running npm update/upgrade includes the code that changed in the dependencies in the commit.

Surely there has to be better ways of “vendoring” (including hosting your own package repository that doesn’t automatically pull new versions) than adding thousands or maybe tens of thousands of files to the git repo?

If my podcast memory serves, that's how Isaac (the NPM guy) said it was intended.

You would `npm install` and then `git commit`. That's why npm didn't have a lock file back then. Git was the lock file.

if it's dumb and it works it isn't dumb!

another rather simple solution is a git mirror of each package, then point npm to a git url

On debian I do debdiff to see the differences between two source packages.

This is an option but that makes it easier to conceal malicious code within node_modules as an internal threat actor or make super sure there's a culture of actually reviewing those changes.

In cases like that it helps to do npm install on the CI and make sure you end up with identical code. Decent trade-off.

this is an area that is top of mind for me right now. you don't have to vendor your deps to get a detailed report of what changed, and bonus, how your app calls into it. just wrote about it: https://edgebit.io/blog/code-diff-reachability/