Cloned project with dynamic includes in composer.json - php

Question

I have an application server, it is like a blog system (my wordpress killer). It is based in php hosted in github and using composer to manage dependencies. Each installation is hosted in my server (I make the installation for them). When a client requires a new "addon/plugin" I create a new package and host it in a private repository hosting. The problems comes when I need to add new package:
Client 1.
- package for calculate prices
Client 2.
- package for show a welcome message
Client 3.
- package for add a calendar
My application will have every package ready to be used in all instances because I am requiring them via composer:
"require": {
"killer/calculate": "dev-master",
"killer/message": "dev-master",
"killer/calendar": "dev-master"
}
Now image if I have 2K clients and everyone of them are requesting custom packages. How can I provide an application (cloned massively) but just keeping in the each installation just the packages that each client need?
Hypothetical solution
I was searching (if it is possible) for something like the following. For each installation, create a file manually where its content specifies the package to be required. For example, let's say each client's installation has something like this:
//composer.json
"require": {
}
//plugins.json (this file is ignored via .gitignore)
{
"killer/calculate": "dev-master"
}
Then, somehow tells to composer.json to require the data from plugins.json. By this way I am avoiding to create a huge composer.json sharing unnecessary packages for all clients.

Answer 1

There is a feature request for allowing composer.json to extend another file. You should go comment on it to draw some attention to it.
The way you would use that feature is to create a default.json file that contains all your regular composer.json contents, including a require section that lists all the common packages you need.
// default.json
{
"require": {
"php": ">=5.4.0"
}
}
Then have a composer.json file for each project that extends and/or overrides default.json like this:
// composer.json
{
"require": {
"killer/calculate": "dev-master"
},
"extends": "default.json"
}
The final result would be:
{
"require": {
"php": ">=5.4.0",
"killer/calculate": "dev-master"
}
}
If you can't wait on the merge request, then you can go checkout the composer fork from the merge request's author and try it out.

Answer 2

Sounds like you have created your own package ecosystem. So, you could work independently from Packagist and simply host all the packages yourself, probably using Satis.
The main suggestion i have is to introduce your application as a package into this ecosystem.
Your application composer.json contains only the packages relevant for the application itself.
{
"name": "better/application",
"require": {
"another/library": "1.0.0",
"another/framework": "1.2.3",
"another/generator": "2.1.3"
},
"require-dev" : {
"phpunit/phpunit" : "4.*",
}
}
I think, that "cloning" the application for the customer/client is not a good idea, because it ignores that plugins have dependencies on a specific version of your application, which is not always "latest" or "dev-master". Let Composer pull the application by version for each client.
By this way I am avoiding to create a huge composer.json sharing unnecessary packages for all clients.
create one repository per new customer/client
add the application itself and the packages requested by the client inside composer.json
add a client config on top
For instance, the composer.json for Client1:
{
"name": "better/application-for-client1",
"require": {
"better/application": "1.0.0",
"better/app-calculate": "1.2.3"
}
}
For instance, the composer.json for Client2:
{
"name": "better/application-for-client2",
"require": {
"better/application": "1.0.1",
"better/app-calculate": "1.2.4",
"better/app-message": "2.0.0"
}
}
Each customer might have its own setup, requiring different version of your application with different additional application packages/plugins (here indicated by using the prefix "app-").
In the end you have two essential files for a customer: a composer.json and a configuration file.
(How the application detects the available modules is another story. At least, the autoloading will work out of the box, when you register Composers Autoloader during the bootstrap of the application.)
(Sidenote: If your application is a multi-site application, then you might replace "cloning" by "symlinking". With multi-site, i mean an application which runs from one central place using a site id (often customer id). If you have the application folder with all packages for development in one monolithic folder, then build a relase folder by cleaning the development stuff out, so that you get a release version with a blank default config. Then symlink the application, the requested packages to the customer folder and place a configuration on top. This approach might save quite a bit disk space and doesn't involve Composer at all.)

Answer 3

I would also encourage you to use the approach proposed by Jens A. Koch in his answer, having a composer.json file for each customer and requiring the main application and all required plugins. Composer supports this scenario quite well and I want to point you to the starting points:
Composer Types
Composer allows to specify types for packages. You can define your own type to mark plugins for your application as such. Many open-source projects (e.g. Symfony with bundles) have adopted this approach for their plugin eco-system.
Custom Installers
You can register custom installers that can execute for a specific type of composer package (i.e. the type you defined for your plugins). Then you can customize the installation process for your plugins, which means you can:
move your custom plugins to specific locations,
automatically adjust plugin configurations,
and most importantly: provide a mechanism that allows the main application to see which plugins are available.

Answer 4

Hmm.. require all packages ones..
It means one big composer.json for everything is running with your system / is compatible with your system. Maybe you will have to introduce a versioning system too.. So you could end up with v1_composer.json ..
But for each client load only the required packages. For example generate a requires.php for each client with necessary require statements which links to your shared libraries.. This will be the fastest solution and most efficient, because you sharing the code which you can share and you only load it when needed
Conclusion
Share as much code as possible... but don't use it when you don't need it.