For framework and container developers

Making your project compatible with universal modules!

So you are a framework developer or a container developer and are looking to add support for univeral modules in your project? Welcome!

Adding support for service providers

Essentially, adding support for universal modules means adding support for container-interop's service providers.

There are essentially 2 strategies here:

The container contains the configuration

Configuration MUST be available from the container.

Each framework stores configuration in a different place.

The only way to make configuration available in a framework agnostic way is to make it available in the container.

This means that $container->get('DB_HOST') should return the DB_HOST parameter stored in the configuration if it exists.

Many frameworks out there treat configuration and services as 2 different beasts and do not make configuration available in the container. If you are in this case, you can still use universal module by providing the service providers with an adapter around your container. The adapter will check both the container and the configuration.

Check the Symfony adapter or the Laravel container adapter if you need some examples.

Automatic discovery of service providers

Frameworks MUST support service providers discovery using the Puli binding by default.

This way, users of your framework will just have to require the universal module in Composer and automatically, your framework will detect and embed the service provider in the container.

You should also offer an option to completely disable Puli.

Of course, users can also manually disable Puli bindings to remove one particular service provider.

Performance optimizations

TODO: explain integration with container-interop/common-factories