The repo doesn't get big because the dependencies are huge at a point in time (though they may be); it gets big because they change over time, and history gets

The repo doesn't get big because the dependencies are huge at a point in time (though they may be); it gets big because they change over time, and history gets huge and intensely messy in this situation. Shallow clones, branching, and fetch tuning are band-aids on this, which, over enough time (which in practice can be as short as months on a big project being iterated on by tons of people) will still cause clone/deployment problems, repo storage problems, and lost time. And don't start with the "well then just break it up into multiple git repos!" stuff. That's not only incredibly hard to do in practice/in the face of legacy, but it's fundamentally just another constant-factor mitigation on the problem. Sometimes, checking in all the deps makes sense. Sometimes it doesn't. Big node projects are a situation where it often doesn't.