Timeline for Should composer.lock be committed to version control?
Current License: CC BY-SA 4.0
26 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 16, 2022 at 23:51 | comment | added | Stephane Gosselin |
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.
|
|
| Feb 23, 2022 at 8:20 | comment | added | Carlos Mora | 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. | |
| Jul 13, 2021 at 20:50 | comment | added | Arbitrary | 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. | |
| Jul 1, 2021 at 21:01 | comment | added | SteveExdia | 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. | |
| Sep 8, 2020 at 5:20 | comment | added | AntiCZ | 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. | |
| Mar 26, 2020 at 20:48 | history | edited | Josh Johnson | CC BY-SA 4.0 |
Fixed types, removed fluffy wording
|
| Mar 20, 2020 at 15:11 | comment | added | Arno Schäfer | 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. | |
| Jan 8, 2020 at 11:58 | comment | added | nfo | 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) | |
| Nov 20, 2019 at 9:54 | history | edited | MC Emperor | CC BY-SA 4.0 |
Slightly improved grammar.
|
| Oct 28, 2019 at 20:38 | comment | added | ToolmakerSteve |
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?
|
|
| Jun 21, 2019 at 0:58 | comment | added | billrichards |
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.
|
|
| Apr 30, 2019 at 9:28 | comment | added | Eric MORAND | 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. | |
| Jul 16, 2018 at 14:27 | comment | added | Evan Donovan | 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. | |
| Jan 18, 2017 at 17:37 | history | edited | Josh Johnson | CC BY-SA 3.0 |
Edit asking for comments on downvotes
|
| Jun 14, 2016 at 15:20 | comment | added | Sven |
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.
|
|
| Mar 15, 2015 at 1:15 | comment | added | Nathan J.B. | @CEPA - That's odd. I would have expected it to fail if the hash couldn't be found. Seems dangerous. | |
| Jan 8, 2015 at 15:27 | comment | added | CEPA |
@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).
|
|
| Aug 6, 2014 at 16:08 | history | edited | Josh Johnson | CC BY-SA 3.0 |
Removed weak wording
|
| Jul 22, 2014 at 15:37 | comment | added | Josh Johnson | @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. | |
| Jul 21, 2014 at 23:39 | comment | added | borfast | @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 :\ | |
| Jul 21, 2014 at 18:56 | comment | added | Josh Johnson |
@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.
|
|
| Jul 19, 2014 at 9:04 | comment | added | borfast | @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. | |
| Mar 21, 2014 at 21:25 | comment | added | Quinn Comendant | 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. =) | |
| Mar 20, 2014 at 16:32 | comment | added | Josh Johnson | 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. | |
| Mar 19, 2014 at 23:23 | comment | added | Quinn Comendant |
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, in bold, "Commit your application's composer.lock (along with composer.json) into version control". Choose wisely =)
|
|
| Feb 5, 2014 at 21:59 | history | answered | Josh Johnson | CC BY-SA 3.0 |