Agreed on not exposing the Loader - I've just fixed both issues!

@stof I went backwards and re-added the getResourceLoader at sha: 92e419d. I did this so that I could pass the original LoaderInterface to configureServices(), instead of the wrapper ContainerBuilderAwareLoader, which could be more useful in edge cases.

I've just drastically simplified this PR and updated the description to describe it. This is ready for review!

@weaverryan can you give me a use case on why you would choose to have a new kernel whose goal is to be able to build an application without any external files ?

Thank you :-)

@dupuchba Good question. Here are some reasons:

1. Remove the idea that Symfony is big and complex. In reality, we're very few steps from being able to create an entire app (services & routes) in a single file. That's a powerful concept to illustrate.

2. Make Symfony better for creating micro-services and prototyping.

3. This makes configuration simpler. You can load YAML files like normal, but you also have the option to use logic in here for configuration, which allows you to have environment-specific behavior, without the config_ENV.yml setup (which works well, but is overhead if you want to keep things small).

4. Easier to submit bug reports - instead of cloning the SE, you could build a tiny project with this one file (+ whatever other classes, e.g. form types, needed for the bug).

I think this is superior to the normal Kernel. If the SE used this, nothing would change, except that users would be passed the ContainerBuilder and have the option to configure it in PHP (this is possible now with the ClosureLoader, but not obvious).

Cheers!

@weaverryan you convinced me as at work we are currently migrating to a micro service architecture. Very interesting project!

ping @symfony/deciders

👍 another step in the right direction!

Probably I miss an important point here, but I don't see right now how this really makes things much easier.

@weaverryan Can you show a simple example on how I would use this in a real application?

@xabbuh I have a (somewhat complex) kernel example here (+route integration, which isn't part of this PR, but you can see how the kernel could handle both): https://gist.github.com/weaverryan/e4b19cabb1d9286c4217

Adding services in php is certainly not objectively better, but I think the approach of configureServices is better than what we have now - I listed some reasons earlier: #15820 (comment).

Here's the big win for me: End users would now implement configureServices instead of registerContainerConfiguration and have the option to load an external file (like before), or add services directly (or load external files and then use some php logic to mutate those definitions, e.g. for environment differences).

Make sense?

@weaverryan Thanks for the example. I think I now understand your approach better. :) Besides the minor comments I left, I like this approach. 👍

@xabbuh thanks for the review!

👍

Status: Reviewed

What about this?

<?php

namespace Symfony\Component\HttpKernel;

use Symfony\Component\Config\Loader\LoaderInterface;
use Symfony\Component\DependencyInjection\ContainerBuilder;
use Symfony\Component\DependencyInjection\ContainerInterface;

abstract class MicroKernel extends Kernel
{
    public function registerContainerConfiguration(LoaderInterface $loader)
    {
        $loader->load(function (ContainerBuilder $container) use ($loader) {
            $this->configureExtensions($container, $loader);
            $this->configureServices($container, $loader);
        });
    }

    protected function configureExtensions(ContainerBuilder $c, LoaderInterface $loader)
    {
    }

    protected function configureServices(ContainerBuilder $c, LoaderInterface $loader)
    {
    }
}

I'm going to submit a PR soon with my own version of a micro-kernel.

see #15990

Closing this one as #15990 provides an easier approach.