I'm trying to understand this part: http://getcomposer.org/doc/02-libraries.md#lock-file
this lock file will not have any effect on other projects that depend on it. It only has an effect on the main project"
Does that mean that if project P depends on library A, and library A depends on library B v1.3, project P won't care about the version of library B, and will possibly install B 1.4 instead? What's the point then?
Or does it mean the opposite, as one would expect from a dependency manager?
composer.lock records the exact versions that are installed. So that you are in the same versions with your co-workers.
composer install
Check for composer.lock file
If not, auto generate composer.lock file (Using composer update)
Install the specified versions recorded in the composer.lock file
composer update
Go through the composer.json file
Check availability of newer (latest) versions, based on the version criteria mentioned (e.g. 1.12.*)
Install the latest possible (according to above) versions
Update composer.lock file with installed versions
So in a simple check list.
If you want to keep all co-workers in the same versions as you...
Commit your composer.lock to GIT (or vcs you have)
Ask others to get the that version of composer.lock file
Always use composer install to get the correct dependencies
If you want to Upgrade the system dependencies to new versions
Check the composer.json file for version specs.
Do a composer update
This will change the composer.lock file with newest versions
Commit it to the GIT (or vcs)
Ask others to get it and composer install
Following will be a very good reading
https://blog.engineyard.com/2014/composer-its-all-about-the-lock-file
Enjoy the power of composer.lock file!
Composer dependencies are defined in composer.json. When running composer install for the first time, or when running composer update a lock file called composer.lock will be created. 1
The quoted documentation refers to the lock file only. If your project P depends on library A and A depends on B v1.3.**, then if A contains a lock file saying someone ran "composer update" resulting in B v1.3.2 being installed, then installing A in your project P might still install 1.3.3, as the composer.json (not .lock!) defined the dependency to be on 1.3..
Lock files always contain exact version numbers, and are useful to communicate the version you tested with to colleagues or when publishing an application. For libraries the dependency information in composer.json is all that matters.
1 composer.lock is created by default as the lock configuration option[ref] is true. Setting the option to false Composer won't create nor read the composer.lock file.
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.Read more here Composer: It’s All About the Lock File
Related
I'm working on a project based on PHP7 and Laravel. Unfortunately, there was a problem with dependencies and package versions.
I guessed that the previous developer working on the project started updating packages by calling
composer update
on his local dev environment.
Therefore, a new composer.lock file has been generated and everything has been pushed to the production server - however, the composer update command has not been called on the production...
There is a problem with the incompatibility of the PHP version and other errors in dependencies.
This is a very large project and I wouldn't like to migrate now to higher versions on the production server.
I am currently preparing a development environment and I care about maintaining the maximum compatibility of all package versions with what is on production.
By calling:
composer install
on local environment, I'm receiving a series of errors related to the incompatibility of the package versions.
Is there any way to regenerate / restore composer.json and composer.lock based on what is currently installed on the production server? Unfortunately, at this moment composer.lock on production doesn't completely reflect the current state of actually installed versions.
What is a safe and good way to recreate locally a cloned project from a repository on a production server - and maintain full compatibility of all package versions, the correct form of composer.json and composer.lock?
Thanks in advance for your help!
To run composer update and composer install
You can run with this code
composer install --ignore-platform-reqs
Or for update
composer update --ignore-platform-reqs
I found https://www.wuhaiqiao.com/2020/11/24/329.html
No, there is no way to recreate composer.json file based on what is already installed in /vendor. You can look for /vendor/composer/installed.json file as a reference for installed versions of all packages.
What you need to do in this case is:
Make sure your local environment is exactly the same as your production one. You can fake it if needed in your composer.json too by using platform configuration.
Your composer.lock file is of no use. Get /vendor/composer/installed.json file from your production. Delete your /vendor folder.
Run composer install. Write down all packages that have issues and check provided solutions by Composer.
Start downgrading the versions in your composer.json for packages that have issues based to the solutions provided by Composer. Be sure to look into those packages yourself - developers aren't always very strict with the way they maintain dependencies and versioning of their packages. You can always just take package version from production's /vendor/composer/installed.json and place that specific version in your composer.json.
Repeat steps 3-4 until you can finally generate new composer.lock file. Make sure your composer.json and composer.lock files are tracked by your VCS and fixate the changes.
I freshly installed a PHP application given with a composer.lock file.
When running composer install, command line tool is still asking for a composer.json.... I don't have.
In composer documentation, it's said that install command first look for a composer.lock and then for a composer.json.
Why composer is still asking for a file it doesn't need to install my dependencies ?
composer install > returns :
Composer could not find a composer.json file
You still need the composer.json file to install or update any dependencies.
Having a composer.lock file means that composer will not search for the latest commits of the dependencies
A few weeks ago on Twitter, I noticed that the OpenCFP project doesn’t have a composer.lock file in it’s repository. “So what,” you might say, “just composer install and away you go. You’ll get the same dependencies, right?”
Wrong.
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.
Source: Composer: It's all about Lock File
You must have a composer.json to install dependencies, because it's the file where dependencies theirself are listed. Refer to the documentation.
composer.lock lists dependencies which has already been installed. The composer looks first into it in order to keep versions consistent.
The (documentation states)[https://getcomposer.org/doc/01-basic-usage.md#installing-with-composer-lock]:
running install when a composer.lock file is present resolves and installs all dependencies that you listed in composer.json, but Composer uses the exact versions listed in composer.lock to ensure that the package versions are consistent for everyone working on your project.
If you have lost your composer.json you can reverse engineering your composer.lock. Open it and read all the packages installed, then create a composer.json which requires them. Not every single package will be a direct dependency for your problem: you should identify and remove those which are not.
What are the differences between composer update and composer install?
composer update
composer update will update your depencencies as they are specified in composer.json
For example, if you require this package as a dependency:
"mockery/mockery": "0.9.*",
and you have actually installed the 0.9.1 version of the package, running composer update will cause an upgrade of this package (for example to 0.9.2, if it's already been released)
in detail composer update will:
Read composer.json
Remove installed packages that are no more required in composer.json
Check the availability of the latest versions of your required packages
Install the latest versions of your packages
Update composer.lock to store the installed packages version
composer install
composer install will not update anything; it will just install all the dependencies as specified in the composer.lock file
In detail:
Check if composer.lock file exists (if not, it will run composer update and create it)
Read composer.lock file
Install the packages specified in the composer.lock file
When to install and when to update
composer update is mostly used in the 'development phase', to upgrade our project packages according to what we have specified in the composer.json file,
composer install is primarily used in the 'deploying phase' to install our application on a production server or on a testing environment, using the same dependencies stored in the composer.lock file created by composer update.
When you run composer install it will look for a lock file and install whatever is contained in it, if it can't find one, it'll read composer.json, install its dependencies and generate a lockfile.
When you run composer update it simply reads composer.json, installs the dependencies and updates the lockfile (or creates a new lockfile).
composer install
If composer.lock does exist.
Processes and installs dependencies from the composer.lock file.
If composer.lock does not exist.
Process package installs from composer.json.
Creates the composer.lock file based on the installed packages.
As per: composer help install:
The install command reads the composer.lock file from the current directory, processes it, and downloads and installs all the libraries and dependencies outlined in that file. If the file does not exist it will look for composer.json and do the same.
composer update
Processes dependencies from the composer.json file (installs, updates and removes).
Creates or updates the composer.lock file according to the changes.
As per: composer help update:
The update command reads the composer.json file from the
current directory, processes it, and updates, removes or installs all the
dependencies.
See also: Composer: It’s All About the Lock File
composer install
if(composer.lock existed){
installs dependency with EXACT version in composer.lock file
} else {
installs dependency with LATEST version in composer.json
generate the composer.lock file
}
composer update
composer update = remove composer.lock -> composer install
Why we need 2 commands. I think it can explain by composer.lock.
Imagine, we DON'T have composer.lock and in composer.json, there is a dependency "monolog/monolog": "1.0.*" or "monolog/monolog": "^1.0".
Then, it will have some cases
We working well today with current dependency version (eg:1.0.0) but a few
months later, the dependency update (eg:1.0.1) and it possible have some bug
Another team member may have a different dependency version if they run composer install in a different time.
What if we always use an EXACT version in composer.json such as "monolog/monolog": "1.0.1"?
We still need composer.lock because composer.json only track the main version of your dependency, it can not track the version of dependencies of dependency.
What if all dependencies of dependency also use the EXACT version?
Imagine you begin with ALL dependencies which use the EXACT version then you don't care about composer.lock. However, a few months later, you add a new dependency (or update old dependency), and the dependencies of this dependency don't use the EXACT version. Then it's better to care composer.lock at the beginning.
Besides that, there is an advantage of a semantic version over an exact version. We may update the dependency many times during development and library often have some small change such as bug fix. Then it is easier to upgrade dependency which uses semantic version.
The best difference between composer update and composer install
composer install
To add dependencies you need to add it manually to the composer.json file.
If composer.lock file exists, install exactly what's specificated on this file
Otherwise read composer.json file to look out what dependencies needs to be installed
Write the composer.lock with the information of the project (installed dependencies)
Not any component will be updated with this command.
composer update
To add or remove dependencies you need to add it manually to the composer.json file
The composer.lock file will be ignored
composer.json file dependencies will be installed and updated (if a dependency is not installed it will be downloaded)
If you can't (or don't know how to add or remove a library which is in fact easy,just add the name of the dependency and version in the require property of the file) modify the composer.json file manually or you prefer use the command line instead, composer has special functions for this :
composer require
For example if we want to add a dependency with the command line we will simply execute
composer require twig/twig
composer.json file will be modified automatically and the new dependency will be added
the dependency will be downloaded to the project
composer remove
If you want to remove an unused dependency we will execute simply :
composer remove twig/twig --update-with-dependencies
Twig will be removed with all his dependencies
In my project I have some Composer vendor libraries that have been manually edited; my purpose is to restore them to the original state, on my development machine.
I unfortunately triggered a composer update so I don't have a correct composer.lock anymore (it has been updated). I got the composer.lock from our production system (that had the same libraries version of the old development composer.lock).
After replacing the new composer.lock with the old one, what should I execute for being sure to have the same environment as before?
Should composer install be enough to reinstall the old versions of the dependencies? (after removing the old Composer vendor/ directory)
I want to reinstall without getting any newer version.
And, in future cases where I will avoid to perform a composer update, what should I have triggered for restoring a vendor library after a manual edit of it?
As answered from Max:
"Yes, composer install will use the composer.lock file"
I just restored the composer.lock from my production system and then performed a composer install.
As stated from Édipo Costa Rebouças, if we commit the composer.lock to our repository every time we update it then we will always have the right reference to the correct versions of the dependencies.
The project is set-up via composer.phar install --prefer-source and contains quite some modules which are kept in git.
I manage all these modules and their git repositories in my IDE (PhpStorm) and so might commit some changes to some of the modules in the vendor/ folder - directly to the source git repository.
How can I make sure now, that my co-workers get my recent module version when doing a composer.phar install (composer.lock is in the repo)?
If I make a local composer.phar update it looks like the composer.lock is not updated, because I already have the latest version (as I just made the commit directly in the vendor folder)
Commit the changes in the modules repos you've updated.
Push the changes to all respective remote repos.
Tag the new changes with appropriate versions.
Run composer update vendor1/package1 vendor2/package2 (or just composer update if you don't need to be explicit).
Commit and push the updated composer.lock file.
Your co-workers need to pull the updated composer.lock file and run composer install (install latest package versions from lock file).
If you have specified versions restrictions such as "vendor/package": "3.5.*" in your composer.json and you have tagged a new version like 3.6.0 you will need to update your composer.json file accordingly before step 4..
P.S. It is very good you use such a workflow with --prefer-source. Please do not use * or dev-master version restrictions in your composer.json. I would recommend always use versions even if they are in the zero major version range (0.X.X).