I work in a team with ~15 developers and we've been asking ourselves: What is the best practise to work with composer?
Our composer.json has ~5 Packages. We use Bamboo as a Continous Integration system and Subversion.
Today, we run composer self-update / composer update and commit the vendor folder into the repository.
It feels kind of wrong to do that. What is the best practise?
You put the requirements (dev and normal) in the composer.json file
You run composer update to update all dependencies
This command creates a composer.lock file, which contains which versions of the dependencies is used.
Commit that file and exclude (ignore) the vendor/ directory
Whenever you want to install the dependencies, you run composer install. This will install all dependencies with the versions stored in the composer.lock file. This means that everyone have the same versions.
Once in a week, someone run composer update to update all dependencies and create a new composer.lock file with the updated versions.
This file gets committed
Everyone runs composer install (once a day or once in 2 days) and gets the new versions installed.
Related
In a project, I have installed one composer in this independent subdirectory, and I have a main composer in the main directory.
Now, I have set up the classmap of subdirectory composer in the main composer, which works. The subdirectory composer.json and other relevant composer files are not required anymore.
I'd like to correctly remove/uninstall only the subdirectory composer, maybe similar to this post.
which composer in both directories returns:
/usr/local/bin/composer
What are the correct commands to remove a subdirectory composer, without accidentally removing the main composer? Or do I just manually do that?
Composer only ever creates/modifies 2 files and the vendor-folder in your project, composer.json and composer.lock from those 2 files it knows which dependencies to install into the vendor folder. Removing them is all you need to do.
You can safely delete the vendor folder and Composer will install the same versions of the dependencies when a composer.lock is present. If there is no composer.lock it works basically like a composer update, meaning it will install the newest versions and create a composer.lock for them.
If you remove all 3 then composer will not recognize what to do and tell you to create composer.json first. This is all you need to remove anything composer-related from a project.
Is there a way to update the .lock file regarding mirrors, without updating versions?
I've started using toran, but it appears composer install is still using github for installing.
composer update updated some libraries, but many of the ones I'm using have not had a version change, and their entry in the .lock appears to be unchanged by the addition of a mirror.
To force Composer into reevaluating all of its install history for a project you should delete vendor/composer/installed.json, which is the internal cache file for what is installed and how. If you remove it and then composer install it will re-evaluate and reprocess the entire installation according to the settings in composer.json and the state in composer.lock.
For each new project, I want to:
Get the latest versions of all packages inside composer.json
Once I have them I no longer want to get the latest - just the version of the first run.
I know I could manually specify latest versions from packagist.org, but Ideally I'd like this automated.
I hope this makes sense.
Thanks
the latest package:
"require": {
"namespace/libname": "#dev"
}
after install of this package, composer will dump all info (and version) to composer.lock. do not remove this file and do not use composer update.
always use composer install because this will force composer to look into composer.lock file for package version
Running composer require vendor/package will consult packagist.org for the most current released version and add both the latest release and the version requirement to get this release and compatible updates later.
This will install only stable versions.
After the initial install, you have two options:
composer install will again install the previously found packages.
composer update will look for updated packages that match the version requirement.
Never run update unattended. A developer should run this consciously and then run the test suite to determine if everything still works (or the continuous integration job does it if available). Especially only run install when deploying to production.
There's always been a note in many Readmes of composer-based projects:
Never run composer update on production server
However, there are times that we want to run composer update on PROD servers to keep current (of course after a thorough test on local server). What's the best way to do that?
You should run on local server.
composer update
Next you should test application and add composer.lock to repository. And on PROD server you should run
composer install
composer update is checking if there are any new versions of the packages available within the limits of the versions given. This will unconditionally install new packages if they are eligible. After that you have to test.
composer install will install whatever is mentioned in the lock file, and if the currently installed packages are not the ones mentioned there, they will get uninstalled or updated.
Of course you want to "update" the prod application. But to update the packages, you run composer install which will update the packages to the TESTED state in the lock file - not to an UNTESTED state because newer versions did appear after you tested.
When there are already some components downloaded in vendor directory .. What is the effect of running install on it and also when running update?
So I had the same question and this is what I found:
composer install
Checks for composer.lock and downloads/installs the dependency versions fixed within the composer.lock file, otherwise it will install the initial composer.json dependencies (essentially calling "composer update") if composer.lock is not located, which creates the composer.lock file. This would be used to initialize composer.lock otherwise only in production to install newly updated dependencies introduced by "composer update", and inserted into composer.lock.
composer update
Installs the newest dependencies specified by composer.json, and updates the composer.lock file. This would be used in dev, and after updating the dependencies the newly updated composer.lock file would be uploaded deployed and "composer install" run.
Old question, but someone will most likely find it useful, I know I would have a couple hours ago.