Should composer.lock be committed to version control?
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 ?
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.
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.
After doing it both ways for a few projects my stance is that composer.lock should not be committed as part of the project. I know that it is easier to do so but please bear with me while I make a case for this.
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 implicity defined.
Also, your project should never have to be rebuilt or have it's dependencies reaquired in each environment, especially prod. Your deliverable (tar, zip, phar, a directory, etc) should be immutable and promoted through environments without changing state.
Edit: I knew going in that this wouldn't be a popular answer, but if you down vote would you be kind enough to provide a reason in the comments that points out the flaw in the answer? Thanks!
链接地址: http://www.djcxy.com/p/35486.html上一篇: 在版本控制下使用IPython笔记本