Illuminate/Framework is a unique package grouping all the Illuminate/* namespace. So it's not made of multiple packages, it's an unique package that contains all (one composer.json at the root)

However, to enable more control, each subpackage (in this case each namespace) contains his own composer.json to enable it to be used as a standalone package (example: https://github.com/laravel/framework/blob/master/src/Illuminate/Auth/composer.json )

As you can see, the main composer.json ( https://github.com/laravel/framework/blob/master/composer.json ) define each subpackage in the replace section (to specify what this top level package contains)

So, in your case you can do multiple separated packages with multiple git repos that require each other, or one top level package in one git repo containing all others (and replacing them in composer.json) Personnaly I prefer the multiple package approach, but that's because I have components that can work alone and there is no point having them as a all in one pack.

Hi atrakeur,

artisan workbench alainbelez/package1 --resources
artisan workbench alainbelez/package2 --resources
artisan workbench alainbelez/packagexx --resources

is creating sub packages similar to creating "main" packages as stated above? then move the folder to the main package and fix namespace. correct?

Well, the --resources switch create some laravel specific directory structure. To work correctly and avoid confusing others, this structure must be kept as is. So yes you can move all your php classes in a subnamespace of \Alainbelez\mainpackage if you want to, but I recommend you to avoid moving other things like public assets.

The problem now is that public assets don't belongs to the package they are used with. And your seperated packages are no longer standalone (so no point doing them separated).

So in your case, the multiple package approach seems to be the way to go to avoid making overly complicated structure and messing things up.

Simple things are always better.