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..).