It's actually quite interesting to compare best practices of people who have > ~5 years of experience vs. those who have less than that.
The latter say "Use package managers. Use SemVer. Automatically upgrade to the latest version when it comes out. Check in your package.json, but don't check in your node_modules."
The former say "Check any dependencies on third-party software into source control, and always build from source. If you use a different build system from the original package, write the appropriate files & tools to build it with your own build system. Use new versions only after they've been proven safe with your software. Budget significant time and manpower each time you need to upgrade the version of your dependencies."
The other interesting thing is that this distinction has been in force for at least 15 years. It's not something related to just the Node.js ecosystem, nor to tooling that was recently developed. I can recall being that junior developer in 2000-2002 saying "Let's just write a few shell scripts to run RPM and PEAR install, and everyone can run them to bring their local installations up to date", and being overruled with "No, we're checking this code into the repository with all the appropriate license files and build rules." I think it's really because version breakage is something that will hit you and cause a monetarily-significant loss about once every 5 years, and so until you've been burned by it or worked with someone who has, you'll always gravitate to the more convenient package-manager approach.
The latter say "Use package managers. Use SemVer. Automatically upgrade to the latest version when it comes out. Check in your package.json, but don't check in your node_modules."
The former say "Check any dependencies on third-party software into source control, and always build from source. If you use a different build system from the original package, write the appropriate files & tools to build it with your own build system. Use new versions only after they've been proven safe with your software. Budget significant time and manpower each time you need to upgrade the version of your dependencies."
The other interesting thing is that this distinction has been in force for at least 15 years. It's not something related to just the Node.js ecosystem, nor to tooling that was recently developed. I can recall being that junior developer in 2000-2002 saying "Let's just write a few shell scripts to run RPM and PEAR install, and everyone can run them to bring their local installations up to date", and being overruled with "No, we're checking this code into the repository with all the appropriate license files and build rules." I think it's really because version breakage is something that will hit you and cause a monetarily-significant loss about once every 5 years, and so until you've been burned by it or worked with someone who has, you'll always gravitate to the more convenient package-manager approach.