Two alternatives:
- The occasional alert from `npm audit` that you have to carefully, deliberately, and thoughtfully upgrade your way out of.
- The shifting sands of 100s or 1000s of towering deps that change literally every time you `pnmp install`.
The second one is the current situation and it is madness.
There should be no package lock because package.json should be the package lock.
Though pnpm does have a setting to help with this too: https://pnpm.io/settings#resolutionmode time-based, which effectively pins subdependencies based on the published time of the direct dependency.
Thank you, I'll check it that setting!
We should strive for software to do one thing well (or at least be made up of modular parts that do one thing well) and prize backwards compatability, so that it does not require constant churn.
The sane middle ground between "constant upgrades" and "never upgrade" is to upgrade when there is an actual vulnerability found in a dependency. Instead of churn for no reason, you update only with a good reason.
Do you only write utilities that are fire and forget? Most people write applications whose specifications constantly evolve.