Some people prefer to commit them (along with composer lock files for php). I always advise against it for this exact reason and because I want to make sure packages are correctly installed on the target system. Occasionally, deeply flawed versions are removed and it helps with catching it as well since you are forced to reinstall packages on a pull or build.
Edit: a minor version update should not be backwards incompatible and break things. If it does, the package is poorly maintained imo.
There is also that. But one can reference the exact version and it becomes a non issue. In a properly secure environment it might be desirable. But as with everything there are pros and cons to each approach.
With NPM, this is not true. You can reference exact versions in every single entry in the package.json file and it doesn’t matter.
Each one of those exact versioned libraries you referenced will itself likely have semantic version dependencies which may update themselves. Unless every single dependency you depend on also follows the policy of pinning to exact versions (and their dependencies do the same, and so on), you are still vulnerable (See left-pad incident, which was a sub-dependency of babel).
The only way to avoid this is the old shrinkwrap or the new package-lock.json feature.
Edit: a minor version update should not be backwards incompatible and break things. If it does, the package is poorly maintained imo.