Steps to reproduce:
- Start a Node project that uses at least five direct dependencies.
- Leave it alone for three months.
- Come back and try to install it.
Something in the dependency tree will yell at you that it is deprecated or discontinued. That thing will not be one of your direct dependencies.
NPM will tell you that you have at least one security vulnerability. At least one of the vulnerabilities will be impossible to trigger in your particular application. At least one of the vulnerabilities will not be able to be fixed by updating the versions of your dependencies.
(I am sure I exaggerate, but not by much!)
Why is it like this? How many hours per week does this running-to-stay-in-place cost the average Node project? How many hours per week of developer time is the minimum viable Node project actually supposed to have available?
Or if you leave that alone, and update your package-lick.json so can install exact dependencies with
npm ciYeah this, setting exact dependencies in package.json is a beginner misunderstanding of how package resolution works and is actually counterproductive.
Package.json is where you specify what version ranges your code is compatible with and should be as broad as possible. This makes it more likely that transitive dependencies on the same package will overlap, so the smallest possible number of libraries are included.
When you install for the first time the dependencies are resolved to exact versions and stored in the lock file, and they won’t change on subsequent installs without developer intervention.
So putting exact versions in package.json doesn’t do anything apart from practically guarantee you’ll include multiple versions of each dependency in your project.