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.
Related
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 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
Normally I do install Laravel 5.1 by following this command regarding to documentation:
composer create-project laravel/laravel --prefer-dist
It works fine.
But I read in the documentation under "Via Laravel Installer" also it is possible to install via Laravel Installer, which is much faster than installing via Composer:
laravel new blog
But to use this method I need to run following command once:
composer global require "laravel/installer=~1.1"
When I do run it I get following errors many times
Deprecation Notice: Composer\Package\Version\VersionParser::parseLinks
is deprecated. Use \Composer\Package\Loader\ArrayLoader::parseLinks()
instead in
phar://C:/ProgramData/Composer/bin/composer.phar/src/Composer/Package/Version/VersionParser.php:226
after many line of same error ./composer.json has been updated appears and it continues with the same line of errors, it ends with following
Loading composer repositories with package information Updating
dependencies (including require-dev) Nothing to install or update
Generating autoload files
What is wrong with it? Any idea or solution.
My environment: Windows 10, GitBash and cmder console.
Update of composer, I did ran composer self-update also
Snapshot of console
EDIT:
Note, I can confirm after solving the issue that the installation via Laravel Installer method is faster than composer.
The Composer Assets Plugin you've installed locally is using a deprecated method of Composer. The plugin is already fixed, so run composer global update to get the latest versions with the bug fix. After it, you should be able to run the command succesfully.
If this doesn't work (as you might get the same error running the previous command), try removing the global vendor directory. When running any global Composer command, it outputs something like "Changed current directory to XXX". Remove the XXX/vendor directory and then try running the command.
In addition to #WouterJ answer.
Worst case if the steps provided by #WouterJ did not work, you could manage to uninstall and reinstall composer for windows.
When done, run composer global update to be sure to get latest updates, if there was.
Then run composer global require "laravel/installer=~1.1" and it should works.
Remember to update your windows environment path C:\Users\UserName\AppData\Roaming\Composer\vendor\bin
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.
Is it possible to reload all the packages installed using composer? I'm not sure if I made an accidental change to the source of on of the packages, and my app stopped working so I want to rule this out by reloading all the packages.
You can generally just wipe the vendor/ directory and then run composer install to get everything back from your last known state (stored in composer.lock). Some plugins/custom installers in some frameworks however drop packages outside the vendor dir, but as far as I know with Laravel you should be ok doing this.
I think php artisan dump-autoload should help.