[FIXED] i'm forced to do composer update after each svn update

Issue

how to solve an issue, when several developers working on the same project using laravel framework have different local laravel/vendor/composer/* files?

imagine we have a production server, where we are not running composer anymore (or shall we?). to put all files to production, a developer must do the composer update locally, so laravel would dynamically create/change files such as those in the folder vendor/composer/. than developer commits those files to production and it works.

but after commit of my colleague, i want to update my svn. this means it will also update the dynamically created files, which will miss for example my current working changes. so i have to run composer update myself on my local instance to implement colleague's changes and also to have my current (still non-commited) changes included.

is this a normal good practice, to always run composer update on localhost after each svn update?

Solution

Many questions, but I think I understand what your issues are.

First of all make sure that you don't have the vendor directory version controlled. Both composer.json and composer.lock should be under version control.

If someone has installed a new package via composer, all other developer should do a "composer install" after getting new code.

In production you always run "composer install", never "composer update".

"Composer update" should be ran in a controlled manner, because what that does is that it updates all packages with new versions (occording to composer.json settings).

Answered By - Mattias Hallström