@barbushin opened this Issue on July 20th 2015 Contributor

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.



See http://stackoverflow.com/questions/12896780/should-composer-lock-be-committed-to-version-control

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

@quba commented on July 20th 2015 Contributor

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

@mnapoli commented on July 20th 2015 Contributor

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:

  • sometimes we require specific versions because of a specific reasons: in that case we can see it in composer.json and be very careful when updating the version (because we can't add comments in JSON) -> so that's useful to be able to use ~2.1 and in other places 1.4.4
  • we risk updating the versions even less because it's one more step (edit composer.json + run composer update) -> the simpler the workflow is, the better IMO (i.e. just running composer update thepackage is 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?

@barbushin commented on July 20th 2015 Contributor

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

@mnapoli commented on July 20th 2015 Contributor

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

@barbushin commented on July 20th 2015 Contributor

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

@gitMomo commented on August 19th 2019

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.

This Issue was closed on July 20th 2015
Powered by GitHub Issue Mirror