In a non-library repository? Always, that is the main purpose of having it, to be able to install a working set of packages anytime, anywhere. It also prevents breaking changes being introduced in a vendor library and provides a smoother way of upgrading to newer versions of these - you only update when you want to.
For a library or something meant to be used in other people's code? No, it does not really make a whole lot of sense. You would usually provide a range of versions for each package for which your code works and let the user deal with sorting out the dependency map. Since you have to be able to support that range via testing through some CI anyway, a lock file would get constantly changed, which seems quite redundant. Also, it bloats the repository with a big file that never gets used in the target project, since only the top level lock file defines which version gets installed.
In a non-library repository? Always, that is the main purpose of having it, to be able to install a working set of packages anytime, anywhere. It also prevents breaking changes being introduced in a vendor library and provides a smoother way of upgrading to newer versions of these - you only update when you want to.
For a library or something meant to be used in other people's code? No, it does not really make a whole lot of sense. You would usually provide a range of versions for each package for which your code works and let the user deal with sorting out the dependency map. Since you have to be able to support that range via testing through some CI anyway, a lock file would get constantly changed, which seems quite redundant. Also, it bloats the repository with a big file that never gets used in the target project, since only the top level lock file defines which version gets installed.
Excellent arguments Piotr, I'll update my opinion about it.