Should I put composer.lock under version control for a library? [duplicate]

Question

In an answer to How to get the exact version of included packages in my private repository, I made the statement that composer.lock should not be put under version control for a package. When installing a package, this file is not used after all.

I've peeked in a set of popular repositories, and most of them do not contain a lock file (like Symfony, Laravel, Guzzle, Monolog). On the other hand, the Doctrine repositories contain that file, and I'd like to know if there is any good reason to do so, or to omit the file.

---

Side note: this is about packages, libraries, however you want to call them. For applications, this is a different thing, as you want to stick to specific versions of each dependency when working together in a team or deploying to other systems. How to handle this different situation is covered in Should composer.lock be committed to version control?, but it does not contain too much arguments for my use case

Answer 1

Since the file is not used in any useful manner when installing the package, as a functionality of the library itself for the end user, it's at least not relevant to the user of the library.

Then the reasoning becomes whether it's useful to the developers of the library to have a locked set of dependencies that they need to perform development tasks, such as specific versions of testing frameworks etc. In those cases the argument can be that the composer.json file fulfils the same role as in a regular application - it locks down the dependencies to those that we know work.

However, there's a caveat here - when developing a library you really want the use case to be the same as what the user of the library experiences when he/she installs it. Considering this it usually makes more sense to lock down the explicit version in composer.json instead of relying on the lock file to provide the same functionality. That makes any CI solution install the correct set (the same as what a user would get) of dependencies when for running the tests. You can however make that process update the lock file locally before running the tests to have multiple test cases - one with the locked dependencies and one with the most recent versions (as the user would get).

Doctrine has made the decision that lock files should be committed for their own reasons, which are perfectly valid - in effect they come down to the tools used for their development workflows:

All Doctrine projects must commit the composer.lock file. Tools like phpstan and phpcs are quite fragile on patch releases and we don't want builds to start failing without us having made any changes to our own code. Whenever a dependency needs to be upgraded, the composer.lock file should be updated locally and the change submitted via pull request.

An argument can be made for both cases; it'll be up to the preferences of the project itself and its developers. I'm leaning towards it not being committed, since that more closely replicates what a user would experience when installing the library. However, there would still be local lock files present for each developer, meaning that what each developer has on their own computer when developing the library could differ. Committing the lock file would make that more similar across the board for all developers, but would require extra care to replicate the experience for users (and then, we're back to our original arguments again..).

Answer 2

My post was not about pure libraries, but a kind of module that has many dependencies on other libraries. The module is part of various applications. If, for example, I run a composer install without composer.lock when deploying my application, I might roll out stands that I have not tested. Therefore I fix the dependencies of my module release on a concrete status and of course commit the composer.lock. Therefore, the comparison to frameworks like Symfony is a bit lagging in my opinion, because nothing is deployed here.