composer strategie van laravel en symfony
Eerst even een korte uitleg voordat ik mijn probleem bescrhijf. Ik hoop dat ik hiermee het plaatje een beetje duidelijk kan verwoorden.
Als je bijvoorbeeld kijkt bij Laravel, dan kun je zien dat het begint bij Github.
Daar hebben zij een repo 'laravel/laravel' die alleen de "app", "bootstrap" en "public" folder heeft. Maar ze hebben ook een composer.json bestand die weer verwijst naar de 'laravel/framework' repo. Daar zitten alle componenten in principe in zoals "Routing", Cache" en "Sessions" classes en dergelijke.
Dus als ik Laravel wil installeren met composer dat voer ik dit cmd in:
Code (php)
1
composer create-project laravel/laravel --prefer-dist
Die installeert dus het 'laravel/laravel' project. Wat op zijn beurt weer automatisch het 'laravel/framework' project naar binnen haalt en alle componenten zoals Routing e.d. in de "vendor" folder stopt.
Tot zo ver is het me allemaal duidelijk. Maar nu komt het gedeelte wat ik niet helemaal begrijp:
Ik zei al eerder, de 'laravel/framework' repo heeft de classes "Routing", "Cache", "Sessions" etc.
Maar die Routing class bijvoorbeeld heeft ook weer zijn eigen repo. Alleen is dus niet zo dat er in 'laravel/framework' wordt verwezen (via composer.json) naar de 'Illuminate/Routing' repo, maar naar de class die al in 'laravel/framework' zit.
Nu lijk het zo dat ze developen op de 'Illuminate/Routing' repo. Wanneer deze "goed" is, dan maken ze een release. Die release kopieren ze dan weer naar de 'laravel/framework' repo. Maar wat heeft dat dan voor voordelen?
Waarom hebben ze in de composer.json van 'laravel/framework' niet gewoon een "require" naar de 'Illuminate/Routing' repo? In plaats daarvan gebruiken ze de Routing folder al in de 'laravel/framework' repo zit. Dat is toch niet handig als je elke keer bij een nieuwe release van een component zoals Routing dus, die code ook weer moet over kopieren naar de 'laravel/framework' repo...?
Waarom gebruikt laravel (en symfony) zo'n soort constructie. Ik heb het idee dat hun punt mis.
Ik hoop dat ik het hele verhaal een beetje duidelijk heb kunnen maken. Zo niet, laat het dan weten. Dan probeer ik het op een iets andere manier uit te leggen.
Gewijzigd op 09/04/2014 13:49:53 door D Vivendi
Het verhaal van composer is dat alles wat je wilt hebben van een framework bijvoorbeeld laten we Laravel als voorbeeld nemen kan installeren / updaten met een enkele commando.
wanneer er een update is hoef ik enkel
Code (php)
1
composer update
uit te voeren en hij haalt alle bestanden die ik in de composer.json heb staan op.
Wil ik van versie wijzigen dan wijzig ik de versie in de composer.json en update ik weer.
wil ik ergens vanaf dan haal ik het weg en update ik weer met composer.
Composer is enkel een soort packet manager om packages en frameworks te installeren/updaten/verwijderen. ( beheren ) wat symfony of laravel verder doet of hoe ze dingen uitbrengen heeft hier verder niks mee te maken. Dat bepalen ze allemaal zelf.
Quote:
Nu lijk het zo dat ze developen op de 'Illuminate/Routing' repo. Wanneer deze "goed" is, dan maken ze een release. Die release kopieren ze dan weer naar de 'laravel/framework' repo. Maar wat heeft dat dan voor voordelen?
Deze kopiëren ze niet. Zowel Laravel als Symfony maken gebruik van Git. Deze heeft git substree split, waarmee je een gedeelte van een repo kan splitten naar een andere repo. Alle "component repo's" zijn dus altijd up to date met de full repo.
Quote:
Waarom hebben ze in de composer.json van 'laravel/framework' niet gewoon een "require" naar de 'Illuminate/Routing' repo? In plaats daarvan gebruiken ze de Routing folder al in de 'laravel/framework' repo zit. Dat is toch niet handig als je elke keer bij een nieuwe release van een component zoals Routing dus, die code ook weer moet over kopieren naar de 'laravel/framework' repo...?
Ze hoeven het dus niet te kopiëren, maar dat terzijde. Waarom zouden ze dit willen? Dat heeft voornamelijk praktische redenen:
- Het is makkelijker om 1 project (repo) te beheren (laravel/framework of symfony/symfony) dan enkele tientallen projecten (repo's)
- Het is sneller voor Composer om 1 package te downloaden dan om tientallen packages te downloaden.
Daarnaast zijn al deze losse packages ook nog eens los te gebruiken in elk PHP project.
Gewijzigd op 09/04/2014 17:55:16 door Wouter J