Should composer.lock be committed to version control?

Question

I'm a little confused with composer.lock used in an application with a repository.

I saw many people saying that we should not .gitignore composer.lock from the repository.

If I update my libraries in my dev environment, I will have a new composer.lock but I will not be able to update them into production, will I ?

Won't it generate conflicts on this file ?

Short answer: Yes, commit `composer.lock`. There are reasons to not commit it, but if you're reading this question, they probably don't apply to you. — rinogo, Oct 08 '20 at 19:21
If your composer.lock is not in .gitignore, first : add it to .gitignore file, second : delete this file from repository, end : pull from repository. In this case, composer.lock committed to repository before. When there is file in repository, you can not ignore it, and so must be commit its changes. — Mehdiable, Dec 20 '21 at 10:22

score 779 · Accepted Answer · answered Oct 15 '12 at 13:39

779

If you update your libs, you want to commit the lockfile too. It basically states that your project is locked to those specific versions of the libs you are using.

If you commit your changes, and someone pulls your code and updates the dependencies, the lockfile should be unmodified. If it is modified, it means that you have a new version of something.

Having it in the repository assures you that each developer is using the same versions.

answered Oct 15 '12 at 13:39

meza

8,247
1
14
23

8

Ok but imagine if I update the libraries from the production environment, composer.lock will be overwritten so a next pull from the production will ask me to merge this file... – Pierre de LESPINAY Oct 15 '12 at 13:45
7

If the composer.lock gets modified, you need to push the modifications back to the repository. If you want to tie the software to given versions of the libraries, then do so explicitly in the configuration. That way the lock will never change. Think of the lock file as an indicator of a dependency management issue which needs to be resolved one way or the other. – meza Oct 15 '12 at 13:48
416

In production you should not update your dependencies, you should run `composer install` which will read from the lock file and not change anything. – Seldaek Oct 15 '12 at 13:54
143

"In production you should not update your dependencies" should be written in all caps – Joaquín L. Robles Dec 23 '13 at 12:31
1

@Seldaek I don't know if ```composer install``` should be part of the build/deploy procedure on production (or any remote environment to be honest). I personally prefer deploying the code package after it has been previously "prepared". – Radu Mar 22 '19 at 15:43
@Radu - If using composer, you are doing `composer install` at *some* step of your release cycle, right? My situation is use of `docker` containers and CircleCI (e.g. build/deploy to Amazon AWS). I don't see how one would accomplish this with no `composer install`. For the same reason that when there are multiple developer machines, `composer install` is a recommended step after anyone has changed `composer.lock`. What alternative is there? – ToolmakerSteve Oct 28 '19 at 19:04

score 235 · Answer 2 · edited Aug 03 '17 at 10:55

235

For applications/projects: Definitely yes.

The composer documentation states on this (with emphasis):

Commit your application's composer.lock (along with composer.json) into version control.

Like @meza said: You should commit the lock file so you and your collaborators are working on the same set of versions and prevent you from sayings like "But it worked on my computer". ;-)

For libraries: Probably not.

The composer documentation notes on this matter:

Note: For libraries it is not necessarily recommended to commit the lock file (...)

And states here:

For your library you may commit the composer.lock file if you want to. This can help your team to always test against the same dependency versions. However, this lock file will not have any effect on other projects that depend on it. It only has an effect on the main project.

For libraries I agree with @Josh Johnson's answer.

edited Aug 03 '17 at 10:55

Francesco Casula

26,184
15
132
131

answered Jun 16 '14 at 15:41

Fieg

3,046
1
16
22

Why treat projects at work differently from "libraries"? – Josh Johnson Jul 21 '14 at 19:00
4

Perhaps the use of the word "coworkers" was confusing here, I changed it to collaborators. The main difference is "main project" vs library, in which a main project consists of one or more libraries and code to integrate those. When running composer from the main project it doesn't use a library's composer.lock file, so it installs its dependencies at the latest version. I think this should be similar when testing your library. – Fieg Jul 24 '14 at 11:55
2

Committing the lock-file with a library is probably a good thing - the lock-file documents which versions of dependencies were installed when the test-suite was run. That's particularly important in a team, and especially in continuous integration environments. – mindplay.dk May 08 '17 at 06:49
Non-trivial conflicts can arise when reintegrating in trunk 2 branches that both have new packages installed through composer. Happened right now :) – g4b0 May 11 '18 at 08:58
Symfony and many other PHP libraries I have seen all exclude `composer.lock` from Git, still I don't understand why. Could someone make a use case which justifies it? Thank you! – tonix Dec 26 '18 at 14:18
2

@tonix, I can answer this with some authority! The reason I don't commit composer.lock for my *libraries* is that my CI builds master every night no matter what. It guarantees that if any of the library's dependencies have upgrade problems a user of the library would have, that the CI fails. Works good! – Theodore R. Smith Mar 21 '19 at 06:41
1

@TheodoreR.Smith then you should commit and push your composer.lock from you CI system so that the version you ran CI with is the version that your dependencies are locked to. composer.lock is about repeatability and if your CI worked then you'll want that documented. Of course, if you are always packaging up your vendor folder from CI and deploying it with your code, then you don't need composer.lock at all. – redusek Jul 13 '20 at 22:36
@TheodoreR.Smith Yes you should run composer update from the CI build and push the lock (or not if build fails) like this your users won't have any issue in the first place – Tofandel Jul 27 '20 at 15:25
@TheodoreR.Smith Does your CI rebuilding master every night refer to it running composer install or update every night? I'd think that downloading and installing packages each night wouldn't be a good idea unless composer.json had changes. – SteveExdia Jul 01 '21 at 17:46
@JoshJohnson for reproducibility between installs you need the lock file. Especially if you have no control over the libraries you are using. – Peter Chaula Nov 01 '22 at 14:42

Josh Johnson · Answer 3 · 2020-03-26T20:48:45.820

96

After doing it both ways for a few projects my stance is that composer.lock should not be committed as part of the project.

composer.lock is build metadata which is not part of the project. The state of dependencies should be controlled through how you're versioning them (either manually or as part of your automated build process) and not arbitrarily by the last developer to update them and commit the lock file.

If you are concerned about your dependencies changing between composer updates then you have a lack of confidence in your versioning scheme. Versions (1.0, 1.1, 1.2, etc) should be immutable and you should avoid "dev-" and "X.*" wildcards outside of initial feature development.

Committing the lock file is a regression for your dependency management system as the dependency version has now gone back to being implicitly defined.

Also, your project should never have to be rebuilt or have its dependencies reacquired in each environment, especially prod. Your deliverable (tar, zip, phar, a directory, etc) should be immutable and promoted through environments without changing.

edited Mar 26 '20 at 20:48

answered Feb 05 '14 at 21:59

Josh Johnson

10,729
12
60
83

22

Agreed. I feel it makes more sense to specify dependency versions in `composer.json` where the required versions are more explicitly stated. But if you _don't_ set specific versions, better to commit the `composer.lock`. It's confusing if the versions specified in `composer.json` are different than those installed as per a `composer.lock`. Also it depends on the app (in-house or general release) and its dev cycle. Of course, the composer docs [do say](http://goo.gl/1ZsHal), in bold, **"Commit your application's composer.lock (along with composer.json) into version control"**. Choose wisely =) – Quinn Comendant Mar 19 '14 at 23:23
12

After much soul searching I've decided, on this point, the composer docs are wrong :) I have a rule that I don't add generated material to the VCS; I allow the build process to handle that. – Josh Johnson Mar 20 '14 at 16:32
12

Isn't the code created using your biomechanical key-pressers "generated material"? I'm not sure that is a solid criteria to base a policy on. =) – Quinn Comendant Mar 21 '14 at 21:25
1

@JoshJohnson, this is an honest question, not trying to start a flamewar or anything, because I tend to agree with you and I'd rather not have composer.lock committed into my repository. That's how I do it in Python with requriements.txt but there I am not allowed to specify a branch as a version which will result in unpredictable state every time I update my project's dependencies. So how do you handle a situation where you need a package that doesn't specify a version, and thus forces you to specify a branch instead? Last time I checked, Composer doesn't allow specifying commit hashes. – borfast Jul 19 '14 at 09:04
1

@borfast I'm not sure. You may be somewhat out of luck in that case. Realistically, artifacts shouldn't be backed by VCS but it's become the de facto standard with composer (see Maven for alternatives). In this case you are stuck with the instability of the branch, forking the repo and adding version branches/tags, or checking in `composer.lock`. I'd be curious of your findings. – Josh Johnson Jul 21 '14 at 18:56
@JoshJohnson, I spent quite a bit of time researching this a few months ago and the conclusion I came to is that the safest bet is to just commit composer.lock. Ideally, Packagist would require actual versions for packages and Composer could allow for cloning repositories if the user explicitly asked to. Another option would be for Composer to allow locking dependencies in composer.json with commit hashes but that would be a mess (there's git, svn, hg...). Unfortunately I couldn't find any sane solution for this :\ – borfast Jul 21 '14 at 23:39
@borfast Composer is still in its infancy. It has a long way to go before it has all of the features that tools like Maven and Bundler do. – Josh Johnson Jul 22 '14 at 15:37
5

@borfast I know I'm a little late to conversation so you may have seen this by this point but, you can specify a hash in the `composer.json`. In the `require` section, you can put: `"repo": "dev-master#2633721877cae79ad461f3ca06f3f77fb4fce02e"`. This will 1) go to the branch, 2) checkout that hash, 3) if the hash is not found on the branch, however, it will checkout the head of the specified branch (master in this case). – CEPA Jan 08 '15 at 15:27
5

@CEPA - That's odd. I would have expected it to fail if the hash couldn't be found. Seems dangerous. – Nathan J.B. Mar 15 '15 at 01:15
2

This answer does not explain the build process that is able to work without committing the lock file. In general, your build process is not able to ensure that a specific version from your VCS will ALWAYS resolve to the same specific versions, i.e. you checkout from VCS, run `composer install` and should be done, then deploy to QA and later to PROD. – Sven Jun 14 '16 at 15:20
2

This makes sense to me, since I've read a good bit about how the use of Composer in Drupal 8 has led to problems with Git conflicts. They may be using it "improperly", but it seems to me that auto-generated code shouldn't go into a repo. – Evan Donovan Jul 16 '18 at 14:27
1

I couldn't agree more, Josh. This is auto-generated code, so it's not supposed to be tracked. Plus composer.lock means "I lock my dependencies to these versions" and then explictely say "I don't trust semver and I don't want to be covered by secutiry patches" which is totally stupid. – Eric MORAND Apr 30 '19 at 09:28
`The state of dependencies should be controlled through how you're versioning them (either manually or as part of your automated build process)` is a very good point, but you can put composer.lock and composer.json into version control and still manage build dependencies differently, either manually or through automated hooks. – billrichards Jun 21 '19 at 00:58
My understanding is that the point of including `composer.lock` in your repo, is that this identifies *the exact versions that your test suite ran against*. It sounds like the problem you have is that developers "run composer update" (with no constraints on what updates are allowed?), when they should instead be doing 'something' (a custom script?) that takes the specified versioning (with whatever wildcards are desired), and finds the latest version that matches that constraint. **Why not create a composer.lock file that identifies the exact resulting versions used?** – ToolmakerSteve Oct 28 '19 at 20:38
1

My observation of having the .lock file inside git is a *update loop*, every developer who may just like to install needed dependencies forced other devs also to update their dependencies and so on. (until one developer decides not to commit the composer.lock file) – nfo Jan 08 '20 at 11:58
1

composer.lock should be committed to the repository, because only that ensures that you can restore your code base to an exact previous state. Your code is adapted and tested to a specific version of your libraries. Once you do git update, it is no longer guaranteed that your code works as intended, so you need to re-test everything. If you ever need to go back to a previous state, if you have a history of your composer.lock, you can just do composer install and re-create the exact previous state. If not, all you can do is git update, and you don't know if everything still works. – Arno Schäfer Mar 20 '20 at 15:11
composet.lock should always be commited wihout no exceptions. Reason: someone make a patch on a lib which is not in your composer.json (dependency of your dependency) and this patch is breaking change. Should not happed but we are humans. If this happened you are completely .... If you like your self so commit. – AntiCZ Sep 08 '20 at 05:20
From what I've seen, the composer.json is for specifying dependency version ranges (even if it's just one version of just one package), and the composer.lock file shows you what actually got installed. Then you can compare the differences in .lock files among different server instances if needs be. – SteveExdia Jul 01 '21 at 21:01
I disagree. So, are you basically saying that we should specify exact version to the minor (e.g. 1.5.3) in composer.json? If not, it means that testing environment and production environment have different version of dependencies. Even if the minor version updates are not meant to break anything, we are never sure and it happens sometimes. – Arbitrary Jul 13 '21 at 20:50
Composer will put the result set of dependencies for the environment it was executed. It means that if you have PHP 7.4 in dev and 8.0 in prod, it could dolve to different dependencies sets. It comes from my own experience. – Carlos Mora Feb 23 '22 at 08:20
Your point sound good in theory, and at first glance seems reasonable. The idea of the composer.lock is (rimshot) idempotence. Although sub-package's composer.lock files are NOT read or taken into account, the main composer.json drives the show. The main package's composer.lock definitely needs to be commited "if" you want to be 100% certain that the build you had on develop (from last year, maybe?) will be the exact same build... today. The constraints defined in composer.json allows one to `composer update somepackage` locally , test and commit to have the updated package deployed. – Stephane Gosselin Nov 16 '22 at 23:51

score 45 · Answer 4 · edited Jun 19 '17 at 08:03

You shouldn't update your dependencies directly on Production.
You should version control your composer.lock file.
You shouldn't version control your actual dependencies.

1. You shouldn't update your dependencies directly on Production, because you don't know how this will affect the stability of your code. There could be bugs introduced with the new dependencies, it might change the way the code behaves affecting your own, it could be incompatible with other dependencies, etc. You should do this in a dev environment, following by proper QA and regression testing, etc.

2. You should version control your composer.lock file, because this stores information about your dependencies and about the dependencies of your dependencies that will allow you to replicate the current state of the code. This is important, because, all your testing and development has been done against specific code. Not caring about the actual version of the code that you have is similar to uploading code changes to your application and not testing them. If you are upgrading your dependencies versions, this should be a willingly act, and you should take the necessary care to make sure everything still works. Losing one or two hours of up time reverting to a previous release version might cost you a lot of money.

One of the arguments that you will see about not needing the composer.lock is that you can set the exact version that you need in your composer.json file, and that in this way, every time someone runs composer install, it will install them the same code. This is not true, because, your dependencies have their own dependencies, and their configuration might be specified in a format that it allows updates to subversions, or maybe even entire versions.

This means that even when you specify that you want Laravel 4.1.31 in your composer.json, Laravel in its composer.json file might have its own dependencies required as Symfony event-dispatcher: 2.*. With this kind of config, you could end up with Laravel 4.1.31 with Symfony event-dispatcher 2.4.1, and someone else on your team could have Laravel 4.1.31 with event-dispatcher 2.6.5, it would all depend on when was the last time you ran the composer install.

So, having your composer.lock file in the version system will store the exact version of this sub-dependencies, so, when you and your teammate does a composer install (this is the way that you will install your dependencies based on a composer.lock) you both will get the same versions.

What if you wanna update? Then in your dev environment run: composer update, this will generate a new composer.lock file (if there is something new) and after you test it, and QA test and regression test it and stuff. You can push it for everyone else to download the new composer.lock, since its safe to upgrade.

3. You shouldn't version control your actual dependencies, because it makes no sense. With the composer.lock you can install the exact version of the dependencies and you wouldn't need to commit them. Why would you add to your repo 10000 files of dependencies, when you are not supposed to be updating them. If you require to change one of this, you should fork it and make your changes there. And if you are worried about having to fetch the actual dependencies each time of a build or release, composer has different ways to alleviate this issue, cache, zip files, etc.

Thanks, I think this answer explains why you should version composer.lock, and if not, what the consequences are and if you can live with them. — José Lozano Hernández, Mar 17 '20 at 13:40
That only works in case prod and dev are EXACTLY the same environment. If you have PHP 7.4 in prod and 8.0 in dev, it may result in different dependencies sets. If you include your .lock file, then you should also include your vendor directory. — Carlos Mora, Feb 23 '22 at 08:23
@CarlosMora why would you work with different php version in dev and prod? This can only lead to unknown/undetected bugs since any test you can perform in the dev environment could fail in prod. As an example, you could write code using specific syntax of php 8 that can not be understand by php 7 and even if all your dev tests pass the prod environment fail. — dvdpzzt, Jan 19 '23 at 15:02

score 10 · Answer 5 · edited Jun 20 '20 at 09:12

You then commit the composer.json to your project and everyone else on your team can run composer install to install your project dependencies.

The point of the lock file is to record the exact versions that are installed so they can be re-installed. This means that if you have a version spec of 1.* and your co-worker runs composer update which installs 1.2.4, and then commits the composer.lock file, when you composer install, you will also get 1.2.4, even if 1.3.0 has been released. This ensures everybody working on the project has the same exact version.

This means that if anything has been committed since the last time a composer install was done, then, without a lock file, you will get new third-party code being pulled down.

Again, this is a problem if you’re concerned about your code breaking. And it’s one of the reasons why it’s important to think about Composer as being centered around the composer.lock file.

Source: Composer: It’s All About the Lock File.

Commit your application's composer.lock (along with composer.json) into version control. This is important because the install command checks if a lock file is present, and if it is, it downloads the versions specified there (regardless of what composer.json says). This means that anyone who sets up the project will download the exact same version of the dependencies. Your CI server, production machines, other developers in your team, everything and everyone runs on the same dependencies, which mitigates the potential for bugs affecting only some parts of the deployments. Even if you develop alone, in six months when reinstalling the project you can feel confident the dependencies installed are still working even if your dependencies released many new versions since then.

Source: Composer - Basic Usage.

score 2 · Answer 6 · answered Jun 26 '17 at 12:43

If you’re concerned about your code breaking, you should commit the composer.lock to your version control system to ensure all your project collaborators are using the same version of the code. Without a lock file, you will get new third-party code being pulled down each time.

The exception is when you use a meta apps, libraries where the dependencies should be updated on install (like the Zend Framework 2 Skeleton App). So the aim is to grab the latest dependencies each time when you want to start developing.

^{Source: Composer: It’s All About the Lock File}

See also: What are the differences between composer update and composer install?

What about having different versions of PHP (as example) in different environments? What about different OS? There are packages that depends on certain binaries like DOMPdf. — Carlos Mora, Feb 23 '22 at 08:25

score 1 · Answer 7 · edited Apr 08 '20 at 12:45

Yes obviously.

That’s because a locally installed composer will give first preference to composer.lock file over composer.json.

If lock file is not available in vcs the composer will point to composer.json file to install latest dependencies or versions.

The file composer.lock maintains dependency in more depth i.e it points to the actual commit of the version of the package we include in our software, hence this is one of the most important files which handles the dependency more finely.

score 1 · Answer 8 · edited Nov 25 '22 at 21:54

This has been fully answered here in the tread.

TL;DR

Definitely, You should vc the composer.lock

but what I am about to tell is the Why

composer.json role

composer.json is the entry point of the dependency manifest for the php packages.

it has been prescribing for package developers to follow semantic versioning.

so in this way if the api version (x) in x.y.z has been changed, you will be understand that there are things you have to be take care of or you could lock your version to some "~x" version.

not all packages following semversion

But, there were a lot of packages which didn't following the rule (5.3 & 5.4 api levels changed or broken) :

doesn't respect this semversioning principle (api level change)
the new packages were not compatible with the oldest ones api (were not well tested and broken)

solution composer.lock

composer has came up with a solution. another file for locking the package versions. (composer.lock)

it holds the exact packages versions, so if any one want to have the same dependency versions can benefit from it.

keep the manifest the same between all deploys

its worth to mention one of the 12 factor modern web development principles is to keep the dependencies the same along all deploys, so every deploy can test it. and there would be no contraction between them.

for this:

you have to keep the composer.lock under version control

and on the production just:

composer install --no-dev

install everything from your vc controlled lock file. the deps you have been tested completely before.

end users of composer.json & composer.lock

the composer.json is a lean file for the developers to make conclusion about the deps and version.

while the composer.lock is intended to be used byt the deploys (machine) to install the exact version numbers on the deploy.

Analogy

its like the analogy for the ip & domains :

ip (lock file) intended to be used by machines

domain (json) intended to be used by humans

however both human (devs) and machines (deploys) can read and benefits from both but there is a more preferable version for each those.

jgmjgm · Answer 9 · 2019-03-29T23:12:33.720

There's no exact answer to this.

Generally speaking, composer shouldn't be doing what the build system is meant to be doing and you shouldn't be putting composer.lock in VCS. Composer might strangely have it backwards. End users rather than produces shouldn't be using lock files. Usually your build system keeps snapshots, reusable dirs, etc rather than an empty dir each time. People checkout out a lib from composer might want that lib to use a lock so that the dependencies that lib loads have been tested against.

On the other hand that significantly increases the burden of version management, where you'd almost certainly want multiple versions of every library as dependencies will be strictly locked. If every library is likely to have a slightly different version then you need some multiple library version support and you can also quickly see the size of dependencies needed flair out, hence the advise to keep it on the leaf.

Taking that on board, I really don't find lock files to be useful either libraries or your own workdirs. It's only use for me is in my build/testing platform which persists any externally acquired assets only updating them when requested, providing repeatable builds for testing, build and deploy. While that can be kept in VCS it's not always kept with the source tree, the build trees will either be elsewhere in the VCS structure or managed by another system somewhere else. If it's stored in a VCS it's debatable whether or not to keep it in the same repo as source trees because otherwise every pull can bring in a mass of build assets. I quite like having things all in a well arranged repo with the exception of production/sensitive credentials and bloat.

SVN can do it better than git as it doesn't force you to acquire the entire repo (though I suspect that's not actually strictly needed for git either but support for that is limited and it's not commonly used). Simple build repos are usually just an overlay branch you merge/export the build tree into. Some people combine exernal resources in their source tree or separate further, external, build and source trees. It usually serves two purposes, build caching and repeatable builds but sometimes keeping it separate on at least some level also permits fresh/blank builds and multiple builds easily.

There are a number of strategies for this and none of them particularly work well with persisting the sources list unless you're keeping external source in your source tree.

They also have things like hashes in of the file, how do that merge when two people update packages? That alone should make you think maybe this is misconstrued.

The arguments people are putting forward for lock files are cases where they've taken a very specific and restrictive view of the problem. Want repeatable builds and consistent builds? Include the vendor folder in VCS. Then you also speed up fetching assets as well as not having to depend on potentially broken external resources during build. None of the build and deploy pipelines I create require external access unless absolutely necessary. If you do have to update an external resource it's once and only once. What composer is trying to achieve makes sense for a distributed system except as mentioned before it makes no sense because it would end up with library dependency hell for library updates with common clashes and updates being as slow as the slowest to update package.

Additionally I update ferociously. Every time I develop I update and test everything. There's a very very tiny window for significant version drift to sneak in. Realistically as well, when semantic versioning is upheld, which is tends to be for composer, you're not suppose to have that many compatibility issues or breakages.

In composer.json you put the packages you require and their versions. You can lock the versions there. However those packages also have dependencies with dynamic versions that wont be locked by composer.json (though I don't see why your couldn't also put them there yourself if you do want them to be version locked) so someone else running composer install gets something different without the lock. You might not care a great deal about that or you might care, it depends. Should you care? Probably at least a little, enough to ensure you're aware of it in any situation and potential impact, but it might not be a problem either if you always have the time to just DRY run first and fix anything that got updated.

The hassle composer is trying to avoid sometimes just isn't there and the hassle having composer lock files can make is significant. They have absolutely no right to tell users what they should or shouldn't do regarding build versus source assets (whether to join of separate in VCS) as that's none of their business, they're not the boss of you or me. "Composer says" isn't an authority, they're not your superior officer nor do they give anyone any superiority on this subject. Only you know your real situation and what's best for that. However, they might advise a default course of action for users that don't understand how things work in which case you might want to follow that but personally I don't think that's a real substitute for knowing how things work and being able to properly workout your requirements. Ultimately, their answer to that question is a best guess. The people who make composer do not know where you should keep your composer.lock nor should they. Their only responsibility is to tell you what it is and what it does. Outside of that you need to decide what's best for you.

Keeping the lock file in is problematic for usability because composer is very secretive about whether it uses lock or JSON and doesn't always to well to use both together. If you run install it only uses the lock file it would appear so if you add something to composer.json then it wont be installed because it's not in your lock. It's not intuitive at all what operations really do and what they're doing in regards to the json/lock file and sometimes don't appear to even make sense (help says install takes a package name but on trying to use it it says no).

To update the lock or basically apply changes from the json you have to use update and you might not want to update everything. The lock takes precedence for choosing what should be installed. If there's a lock file, it's what's used. You can restrict update somewhat but the system is still just a mess.

Updating takes an age, gigs of RAM. I suspect as well if you pick up a project that's not been touched for a while that it looked from the versions it has up, which there will be more of over time and it probably doesn't do that efficiently which just strangles it.

They're very very sneaky when it comes to having secret composite commands you couldn't expect to be composite. By default the composer remove command appears to maps to composer update and composer remove for example.

The question you really need to be asking is not if you should keep the lock in your source tree or alternatively whether you should persist it somewhere in some fashion or not but rather you should be asking what it actually does, then you can decide for yourself when you need to persist it and where.

I will point out that having the ability to have the lock is a great convenience when you have a robust external dependency persistence strategy as it keeps track of you the information useful for tracking that (the origins) and updating it but if you don't then it's neither here not there. It's not useful when it's forced down your throat as a mandatory option to have it polluting your source trees. It's a very common thing to find in legacy codebases where people have made lots of changes to composer.json which haven't really been applied and are broken when people try to use composer. No composer.lock, no desync problem.

score -1 · Answer 10 · answered Jul 16 '21 at 14:16

For anyone on Heroku, the answer is clear "yes, it should be committed":

If composer.json specifies dependencies of any kind in its require section, the corresponding composer.lock that gets generated by running composer update must also be committed to the repository, or the push will be rejected.

Source: Heroku PHP Support: Activation.