I know that there is official Composer developers position that
composer.lock is the best way to set fixed versions of vendors for project. But after working in many many different projects, I found that finally, it's much better just to use fixed versions numbers in
composer.json and if you google it, you will find many people who think the same way.
May be we should think about it one more time?
I already confused working with Composer in Piwik, because I add some debug libraries for my local use, and got many conflicts with
composer.lock that is not listed in
@mgazdzik asked the same question several times and nothing has changed so I'd say that the answer is no (even though it would make my life easier as well).
The answer in the screenshot (the one from Josh) is out of topic as long as you use
composer install instead of
composer update (which is the recommended practice). This is a common mistake, nobody should run composer update unless they actually want to update a dependency. The answer from "jieg" says:
For application/projects: Yes
Piwik is an application, not a library, so yes we should commit composer.lock (which is what we are doing). I don't see why we should move away from that.
I don't see a reason to use fixed versions, and see the following downsides:
~2.1and in other places
composer update thepackageis good)
Also keep in mind that the good practice of Composer is to commit the composer.lock file for applications (which we are doing). So I'd say it's good to stay with the official best practices.
On the other side, I don't see problems with the current practice (but maybe there are). Could you please list them?
@mnapoli There was a problem for me to use some custom vendors that I added in
composer.json, and getting conflict in Git switching to different branches.
Matt, thanks for your answer - it's very good explanation of how it works for Piwik.
It's still open for discussion though if we have particular issues. But your conflicts with composer.json will still be there even if we use fixed version numbers (as this file will stay committed anyway).
@mnapoli Problem is that modified
composer.lock can't be merged automatically with
composer.lock of another branch. Merging
composer.json when switching between branches works fine.
Versionning composer.lock in your project avoids a large memory load on the server. composer uses lots of memory when calculating dependencies, but not when just installing packages.