The downside of this approach is that this is how you create an ecosystem where legitimate security fixes never end up getting applied. There's no free lunch, you need to decide whether you're more concerned about vulnerabilities intentional backdoors (and thus never update anything automatically) or vulnerabilities from ordinary unintentional bugs (and thus have a mechanism for getting security updates automatically).

Yep. I'm calling it. The churn is more dangerous and fragile than the rot.

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.

I don't think this is realistic in the default npm ecosystem where projects can have 1000s of dependencies (with the majority being transitive with fuzzy versions).

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.

Thousands of dependencies is exactly why you need to do this. It's fragile and dangerous to have thousands of possible changes in your software every time you `pnpm install`.

Thank you, I'll check it that setting!

No, it isn't. Upgrades should be routine, like exercising. With your approach it becomes increasingly difficult and eventually impossible to upgrade anything since it requires moving a mountain. An update a ̶d̶a̶y̶ week makes the tech debt go away.

The reason upgrades have become routine is because modern software is slop.

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.

It's not about managing churn; it's about making it easy to refactor by leaving open the option to use newer versions of libraries, or add dependencies that themselves depend on newer versions of libraries. And the way to do that is to continually pay off the tech debt in upgrading your dependencies.

Do you only write utilities that are fire and forget? Most people write applications whose specifications constantly evolve.