If you have a thorough test suite then it is possible to use a package version pattern such as ~1.1.0, or even ^1.1.0 to allow the package to upgrade automatica

If you have a thorough test suite then it is possible to use a package version pattern such as ~1.1.0, or even ^1.1.0 to allow the package to upgrade automatically when the maintainer releases a new version. Obviously being able to do this is highly dependent on having really thorough test coverage to make sure that automatic package upgrades don't break stuff, but this would be one primary reason for downloading dependencies fresh for each build. But even if you had locked down the package versions it still wouldn't be a good idea to commit the package into your source control. Part of the benefit of hitting NPM to download the package is that package maintainers will often explicitly deprecate a package version that should now be considered outdated, or perhaps which had a security vulnerability. This will show up as a very visible warning message when running npm install. This has alerted me multiple times to issues with child modules I had added to my project, or even grandchild modules that were included by other child modules.