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.
Related
Uncaught Error: Class "Symfony\Component\Cache\Adapter\ArrayAdapter" not found,
but Symphony cache and Doctrine cache has been installed,
my composer.json:
"doctrine/orm": "^2.11.0",
"doctrine/dbal": "^3.2",
"doctrine/annotations": "1.13.2",
"symfony/yaml": "^5.4",
"symfony/cache": "^5.4"
This is most likely because of version differences between your local and hosted environments, e.g. you might be running PHP 7.x locally and PHP 8.x on your hosted environment. This can be a bit of a struggle. The key things you need to know are:
composer.json keeps a list of packages that you have said that your project needs. This is usually listed as point revisions, e.g. 1.x, 2.x, 3.x
composer.lock lists the EXACT versions of the package that was installed when the composer install (or composer upgrade) command was used, e.g. 1.2.3
vendor/ is the resulting folder that was installed as the result of running composer install
When there is no composer.lock file, or composer upgrade is run, then composer will fetch the latest version of the available libraries based on the current environment, e.g. your local machine. If you then pick up the vendor/ folder and upload it to your hosted environment, it may contain code that isn't compatible with the environment there.
I see people recommending to delete the composer.lock and vendor folder on the production machine, and then run composer install again. This is likely to resolve the issue, but it glosses over the fact that the code you're running in production is then different to what you were developing locally. On shared hosting it may not be immediately obvious how to run composer install as you may need access to a shell (e.g. SSH connection)
There are two ways forward - either:
use your control panel to change the PHP version for your site to a version that you are running locally
change your local dev environment to run the same version of PHP that your hosting environment is running
Be sure to always run the same version of PHP on dev and production to avoid these kinds of problems, and take the time to understand the purpose of composer.lock and how it is used to populate the vendor/ folder with the exact code based on your current PHP version.
I have a new server, where multiple clients will host their webapps at. From Wordpress, to laravel, to simple html shizzle.
As you may know, Laravel requires Composer to be installed. This can be done locally, but also globaly. I am wondering (if there are any) about the pros and cons.
Of course, you can run the global installation from anywhere. But can this be a issue for other development projects on the server, or are there security for the global installation?
The disadvantage of using a globally installed composer is this
you're likely using different versions along the development pipeline
you may end up with different results
Just as an example, in a project, we had composer.phar checked in and updated regularly, but we ran into problems when the version we used was already updated to be able to use the ^ operator, however, a different binary was used during deployment, unaware of that operator, and the deployment failed.
The safest bet is to use the same version of composer.phar along the development pipeline. Alternatively, as mentioned before, keeping the globally installed composer regularly updated.
Since we usually use Makefiles in our projects, here's an example of what it looks like:
.PHONY: composer cs it test
it: cs test
composer:
composer self-update
composer validate
composer install
cs: composer
vendor/bin/php-cs-fixer fix --diff --verbose
test:
vendor/bin/phpunit --configuration=test/Unit/phpunit.xml
vendor/bin/phpunit --configuration=test/Integration/phpunit.xml
I would always suggest install globally, it will be easier for you to manage, and you could easily keep it up to date.
In the other projects they will not need to clutter their project with
composer.phar file
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.
I've got a client on a shared hosting environment (which I can't change) and I'm needing to install the Parse PHP SDK, but the host won't allow me to install the Composer package manager. Does anyone else know of a manual install method?
If you have wget/unzip available, just download latest release zip (bellow the release, this file).
Use unzip to unpack package and load it with PSR-4 autoloading (the composer's approach).
Composer isn't meant to be an installer, so you are not expected to run Composer on the production machine. What would happen if during your update process Github would be down? No new website version! And maybe also no old version.
Run Composer somewhere else, and then upload the result to the server, after you verified that everything went well.
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.