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
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 found that web.config is included when I install Laravel with:
composer create-project --prefer-dist laravel/laravel blog
but not when I install Laravel using the Laravel installer, with:
laravel new blog
(as per https://laravel.com/docs/5.8/installation)
I've subsequently found a few other differences e.g. devDependencies versions in package.json, some config settings in broadcasting.php, cache.php, database.php.
Can anyone explain to me what is responsible for this difference? Is one install method 'better' than the other?
Thanks
Chris
The difference between both commands is that the composer command uses packagist to get the latest package from GitHub the first time or a cached version, while laravel new blog downloads a zip file from the Laravel server which has the latest version and uses that. Both commands run the so called 'after install' scripts, creating an environment file and setting the application key.
When you don't want a cached version but a new one using composer, run composer clear-cache first, to delete the local cache composer creates.
If you want to see the difference for yourself, compare the composer.json of the base Laravel project (https://www.github.com/laravel/laravel) and the NewCommand.php file in the src directory of the Laravel installer (https://www.github.com/laravel/installer)
Edit
After running both commands, the only difference I could really find was the order in which some things are done, but both generate a working system. Fun thing I noticed is that laravel new project comes with a yarn.lock file, but without a readme.md and composer composer create-project vice versa.
I'm learning PHP Composer, and have run through several scenarios installing Drupal 8 with it. The most authorative method I found for doing so is at drupal.org in this article.
It suggests the following command to do the initial install:
composer create-project drupal-composer/drupal-project:8.x-dev my_site_name_dir --stability dev --no-interaction
I read up on the stability flag, wondering if I am not understanding it correctly. The most autoritative documentation I found is in this article. If I am reading and understanding things correctly, dev stability means I am willing to accept dev packages as part of my install.
Am I understanding the flag correctly? Is the assumption here that I am running a dev environment only, but for production I'll use different parameters? As far as I know, I should not be using any dev packages on production servers... they don't even get security advisories.
Would love it if someone could give me a digest on what the correct logic in approaching stability is. And, if that doesn't make it obvious as to why dev is the default recommended stability, the reason why dev is suggested.
--stability dev switch does not have any effect in this case, so I would guess this is some leftover from old days (or the result of a lack of understanding how stability flags works in composer). In composer.json of this project there is already defined this setting:
"minimum-stability": "dev",
"prefer-stable": true,
Command explicitly uses dev branch (8.x-dev), so --stability dev does not really do anything. And thanks to prefer-stable settings it does not work that bad as you may think - Composer will install dev version only for dependencies without stable releases (which seems to be only dev dependencies in this case).
But you shouldn't use this command for production installation anyway, since it installs all dev dependencies. You should probably use something like this:
composer create-project drupal-composer/drupal-project:8.x-dev my_site_name_dir --no-dev --no-interaction
or call composer install --no-dev after project initialization.
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 am happily developing a PHP app using Composer on cloudControl.
It's great how it is integrated into the deployment procedure.
However, there's no need for Composer to update on every deploy.
Is it possible to (temporarily) disable Composer, per deployment?
Thanks in advance.
I am not entirely familiar with how cloudControl integrated Composer, but ideally you run should composer update when you see fit, and then commit your composer.lock file, and they would run composer install on every deploy.
If you mean composer updating itself: right now the latest version of composer is downloaded on every push, unless you have one already. Just place the composer.phar file in your project directory and it will be used instead.