Composer & composer.lock in GIT and merge conflicts

Question

Here is our situation:

We have 3 different Laravel projects, and all 3 projects depend on our main project. This main project is a separate Laravel package hosted on our private repo and is used as a dependency for other projects.

Previously, whenever something changed in a Core project, we simply ran an update on our server ourvendor / ourcorepackage on our servers for each project to pull out the main changes. Recently, however, the composer has apparently had serious memory problems when we try to launch an update in our Digital Ocean environment with 512 MB RAM. See: https://github.com/composer/composer/issues/1898

The solution that I always come across is people who say that you should always run the composer installation on your production servers. I can take this from a security point of view, because it can be dangerous if you update a new version of some third-party package that could break your code. But in our case, we only update our own main package so that we know what we are doing, but this memory problem forces us to use the composer installation method, because it requires less memory.

So basically this is our current workflow:

• When something changes in our base package, we need to run the composer to update ourvendor / ourpackage for each LOCALLY project. This creates the composer.lock file

• We transfer the composer.lock file in our repo

• On the servers for each project, we run git pull and run the composer install. This will only update our main package and will work much faster and has no memory problems versus updating the composer.

However, this solution causes 2 problems:

• Since we work with several developers in one project, sometimes we have merge conflicts for the composer.lock file when changing local changes locally.
• Running git pull on the server gives an error: your local changes in the following files will be overwritten with merge: composer.lock Please make your changes or write them down before you can merge.

So what should I do here? Before pulling to the server, delete the composer.lock file? How should we handle merge conflicts for the composer.lock file?

It is a shame that updating the composer suffers from memory problems because this method seems more logical. Just update the required package and you will not come across a composer.lock file.

Please advise how the correct workflow with git and composer should be in our case and how to resolve conflicts above?

Thanks so much for your input.

Answer 1

How can you verify that updating the kernel (or any other dependency that is being updated) does not interrupt the work of projects if it is not executed by the developer?

This is why a normal workflow expects composer update be run on a developer's computer that has enough RAM (i.e. maybe more than 1 GB is set as the memory limit for PHP), and the update should be started manually by the developer (and if it starts automatically continuous assembly integration, memory requirements apply to this machine as well).

There is no way around this memory requirement. A web server with only 512 MB of RAM installed can function as an intermediate server with only some concurrent users present, but should not be used to update Composer dependencies.

Personally, I am fixing the merge conflicts in composer.lock with a very simple system: delete the lock file and run composer update . This will update all the dependencies to the latest versions that meet the version requirements and create a new composer.lock working file which will be committed during the merge.

I'm not afraid to potentially upgrade everything, because either it works as expected, or my tests will quickly detect errors.

I choose third-party packages that I use carefully:

• they should tag their versions, preferably using semantic version control.
• I don’t use branches for release versions (rare cases when someone used them during development were painful)
• they must submit a new major version if they make incompatible changes
• locally developed packages also meet these requirements

This works with approximately 270 packages serviced by our local Satis instance (perhaps this is also a factor that should be considered when trying to reduce the amount of memory - only packages known to Composer can end up in memory: compare the ten thousand packages potentially available on packagist.org , with 270 local packages). 60 out of 270 packages are developed locally by 20 developers and randomly release new versions. Update failures over the past 2 years are very rare and should be handled like other errors: if an incompatibility of the marked version is detected, we release a patch that returns the change and mark the original change with a new major release if an incompatible change is needed.

So, the workflow you are requesting looks something like this:

• At any time, any developer should be able to run composer update on their local computer.
• They should be able to detect if it breaks things on their local machine.
• If nothing is broken, they commit the changes, including the composer.lock file in Git
• The intermediate server runs only composer install and will use exactly the versions that the developer used on his computer.
• If nothing is broken during the production, this version is ready for use in production.

Merging an already committed version on another developer's computer can lead to merge conflicts with composer.lock .

• Resolve conflicts on all other files.
• The composer.lock file must be deleted.
• From here, the workflow, as stated above, that is:
• The developer should be able to run composer update on his local computer.
• They should be able to detect if it breaks things on his local machine.
• If nothing is broken ... and so on.

Answer 2

Another approach (without doing composer update ):

• Copy the new (and deleted) lines from composer.json into a separate text file.
• Use all deleted composer.json and composer.lock files.
• During merge conflict mode, do:
  • composer install
  • For each new package that you wrote down in step 1, run composer require vendor/package:version
  • For each remote package that you wrote down in step 1, run composer remove vendor/package
• Testing !, Commiting, done!

This method will store locks from branches of the remote branch (possibly master or develop ) and updates only new packages.