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:
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.
