Manage composer dependencies for Laravel update and Git

No one?? :(

I'm interested in this also. Is your vendor directory tracked by the git repository, or is it excluded ?

You only need to run composer install when yuo change between the 2 branches,

vendor should be exlcuded from .git and you should commit your composer.lock so when you run composer install you get the exact same versions each time

It´s excluded.

If it were included, there would be no problems (I think), because changing branch, change the vender folder too.. But, I think track a vendor folder, itsn´t a good practice... hence my question for other approachs...

Yep @StefanoRuth, thanks for your answer... But, I mean the immediacy of the changing version... Changing branch with git, it´s almost immediate while the vendor update it´s very slow...

For example, running composer update --profile in actual project, I get the following time:

[7.3MB/0.01s] Loading composer repositories with package information
[7.7MB/1.50s] Updating dependencies (including require-dev)
[308.1MB/25.48s]   - Removing caouecs/laravel-lang (3.0.20)
[308.1MB/27.33s]   - Installing caouecs/laravel-lang (3.0.22)
[308.2MB/27.36s]   - [308.5MB/29.35s] /29.35s]
[308.3MB/33.44s]
[308.3MB/33.46s]   - Removing nikic/php-parser (v3.0.2)
[308.3MB/35.31s]   - Installing nikic/php-parser (v3.0.3)
[308.3MB/35.35s]   - Downloading: 100%[308.6MB/37.35s]
[308.3MB/45.45s]
[308.3MB/45.51s]   - Removing arcanedev/log-viewer (4.3.0)
[308.3MB/46.12s]   - Installing arcanedev/log-viewer (4.3.1)
[308.3MB/46.16s]   - [308.3MB/48.15s] /48.15s]
[308.3MB/50.36s]
[308.3MB/50.37s]   - Removing phpunit/phpunit (5.7.9)
[308.3MB/53.34s]   - Installing phpunit/phpunit (5.7.11)
[308.3MB/53.38s]   - Downloading: 100%[308.7MB/55.49s]
[308.3MB/63.70s]
[148.9MB/65.43s] Writing lock file
[148.9MB/65.43s] Generating autoload files
[149.3MB/72.45s] > Illuminate\Foundation\ComposerScripts::postUpdate
[150.2MB/73.56s] > php artisan optimize
[150.2MB/83.98s] Generating optimized class loader

[150.2MB/144.92s] The compiled class file has been removed.

[150.5MB/145.04s] Memory usage: 150.47MB (peak: 309.27MB), time: 145.04s

updating only 3 dependencies. If I change the branch, need to update all of the dependencies...

Without updates, every composer update it takes the next time...

[7.5MB/0.01s] Loading composer repositories with package information
[7.9MB/1.52s] Updating dependencies (including require-dev)
[307.9MB/21.39s] Nothing to install or update
[149.0MB/21.80s] Generating autoload files
[149.4MB/22.84s] > Illuminate\Foundation\ComposerScripts::postUpdate
[150.4MB/22.87s] > php artisan optimize
[150.4MB/23.48s] Generating optimized class loader

[150.4MB/28.28s] The compiled class file has been removed.

[150.7MB/28.41s] Memory usage: 150.66MB (peak: 308.79MB), time: 28.41s

For reference, this are my dependencies in composer.json

"require": {
        "php": ">=5.6.4",
        "laravel/framework": "5.3.*",
        "laravelcollective/html": "^5.3",
        "laravelista/ekko": "^1.3",
        "caouecs/laravel-lang": "~3.0",
        "vinkla/hashids": "^3.0",
        "barryvdh/laravel-debugbar": "^2.3",
        "cviebrock/eloquent-sluggable": "^4.1",
        "arcanedev/log-viewer": "^4.2",
        "consoletvs/charts": "3.*"
    },
    "require-dev": {
        "fzaninotto/faker": "~1.4",
        "mockery/mockery": "0.9.*",
        "phpunit/phpunit": "~5.0",
        "symfony/css-selector": "3.1.*",
        "symfony/dom-crawler": "3.1.*"
    },

For all this, I look for the experience of other users, to know how they handle these situations or simply have to be resigned to perform the composer update every time..

Thanks!!

When changing branch you should only do composer install not update.

Update is only for fetching new versions of packages

I am thinking of a possible solution to this involving Githooks. I haven't worked out the detail yet, but if I do I will post it here :) It would look something like this:

1. vendor folder is excluded in .gitignore (and composer.json and composer.lock are included), as per usual best practice.
2. The vendor folder itself has a separate git repository of its own
3. A post-checkout githook on the main project git repo then checks out (or creates and composer installs) the appropriate branch of the vendor repo.

I will let you know if I have a chance to try this out - if anyone else does, please let me know :)