A developer has sent me his project to work with, but when ever I try to update or install my vendors everything works great until the very end and it outputs the message be
When you run composer update
, composer
generates a file called composer.lock
which lists all your packages and the currently installed versions. This allows you to later run composer install
, which will install the packages listed in that file, recreating the environment that you were last using.
It appears from your log that some of the versions of packages that are listed in your composer.lock
file are no longer available. Thus, when you run composer install
, it complains and fails. This is usually no big deal - just run composer update
and it will attempt to build a set of packages that work together and write a new composer.lock
file.
However, you're running into a different problem. It appears that, in your composer.json
file, the original developer has added some pre- or post- update actions that are failing, specifically a php artisan migrate
command. This can be avoided by running the following: composer update --no-scripts
This will run the composer update but will skip over the scripts added to the file. You should be able to successfully run the update this way.
However, this does not solve the problem long-term. There are two problems:
A migration is for database changes, not random stuff like compiling assets. Go through the migrations and remove that code from there.
Assets should not be compiled each time you run composer update
. Remove that step from the composer.json
file.
From what I've read, best practice seems to be compiling assets on an as-needed basis during development (ie. when you're making changes to your LESS files - ideally using a tool like gulp.js) and before deployment.
The following works for me:
composer update --no-scripts
this is command for composer update please try this...
composer self-update