Proposition: Running pnpm install should never update pnpm-lock.yaml by default

[kweij]

I am all for semver. I don't use pinned versions in mijn package.json, that is what 🔒 lock-files are for.

I really like the choice PNPM made about differentiating the install and add commands 🙌

One thing I'd like to see is that running pnpm install doesn't update the lock-file. I have read the reasoning behind Yarn's choice to DO update the lock-file and it comes down to this:

Once you have manually modified the package.json the expectation in both Yarn and npm is that when you run another install it syncs with the package.json. In that sense yarn install could almost be renamed yarn sync.

On the topic of syncing, when you run an install with new dependencies you expect the node_modules directory to reflect those changes. Since yarn.lock acts as an assistant to node_modules you should expect it to stay in sync the same way.

Your package.json is the ultimate source of truth, that is your interface to yarn, it's your configuration and it's the only thing you should ever be concerned with. In an ideal world you simply commit your yarn.lock and then never have to think about it again.

This is the explanation behind Yarn's decision. And npm acts the same out of legacy. But times have changed ...

---

I disagree that pnpm install should implicitly updates the lock-file. I advocate for this being an explicit instruction, for the sake of clarity and consistency. When the lock-file is out of sinc with the package.json, this should trigger a ⚠️ warning when running pnpm install. The developer should then explicitly update the lock-file to become in sync with the package.json:

pnpm install --no-frozen-lockfile
## Or a new flag if `--frozen-lockfile` could be removed in favor of being the default
pnpm install --update-lock

If this change would be too much of a breaking change, it could be enabled by a configuration in the pnpm-workspace.yaml:

forceFrozenLockfile: true

---

I would ❤️ to hear the view of others and a proper discussion about the feasibility.

PS: Comming from the PHP ecosphere, I have a lot of experience with Composer which inspired this proposition.

[zkochan]

If the package.json has [email protected] in dependencies and the lockfile has [email protected], it doesn't make sense to not update the lockfile.

[kweij]

If you want the lockfile to stay the source of truth, it should not be updated, even after manually modifying the package.json and running install. It should throw a warning, though, stating that the lockfile is out of sync. But updating the lockfile should be explicit, like it is when performing pnpm add ..., pnpm update ... and pnpm remove ....

This also stimulates using pnpm add ... :)

[zkochan]

This would be a huge breaking change and I don't see a big benefit from it.

[yeikel]

I think that this is a situation where pinning your dependencies in package.json makes sense. The idea of using floating versions in the package.json is to allow the current behavior and resolve new versions as they happen