Well that depends. e.g. yarn has an auto clean feature and a feature to flatten the dependency tree. If you have a well groomed dependency tree, one might want to commit the node_modules folder:

1. Ultimately dependencies end up in your production environment, so folks might wanna review the diff of dependency updates.

2. No need to run yarn install. So if your build server has only access to your git repo, no need to get packages from a remote environment.

3. No need for yarn or npm on non-Frontend dev machines. It will just work with Node installed.

4. If npm or yarn ever cease to exist (or the registries), any commit should still work as intended.

If you have native dependencies, committing node_modules will break cross-compatibility with different platforms.

That's exactly what we were hit with - a mix of Mac and PC developers and everything ploded (this was literally one of our first node projects about 5 years ago we didn't know to not commit node_modules)

All of these (except 3) also get solved by moving dependencies to a hosted npm registry. Something which has been suitable for some projects I’ve worked on. And keeps ’git clone’-times down.

Well, not necessarily. Basically you create a new dependency and a piece of infrastructure _you_ need to maintain and that often still relies on yarn/npm upstream registries.

So if that part of the infrastructure is down, you cannot work. A repo might be more error resilient, because if you check it out, you check it out.