It is a very interesting approach, and, in my humble opinion, deserves a good talk or article with details and delicacies. I am particularly in favor of having entities outside of the AppBundle and controller as a service, however, the use-case for that is not in the reach of the newcomer who probably is more suited to a standard MVC layout.
I would really love to see a fork of the 3.x with this as a starting point and work from there.

@sh4ka Basically I want this to start out as a more advanced usage. Once something is standing as is, I would like to iterate over it with DX to make it easy to use for new developers (or maybe even do all at once). Having no bundles means a new-comer could actually skip having to be told about bundles (and what they are), they can just get going.

compiler passes can also be registered in the kernel, by overriding prepareContainer. Be careful to call the parent method at the beginning, otherwise you will break the usage of bundles.

Prepending extension config is useless, as the kernel controls the main loading of the config. Just loads an extra config before the loading of the config_dev.yml file in your registerContainerConfiguration method. It will do the same (prepending config is a way to fake this when you don't have control on the loading)

so the only missing point is the possibility to inject extra classes in the class cache

@sh4ka having entities outside bundles is supported by DoctrineBundle since years. It requires a bit of config though, as DoctrineBundle cannot automatically discover them (there is no convention for finding entities outside bundles, as the convention is precisely based on bundles, so this goes into the configuration way)

@stof I know about that functionality in Doctrine, is very handy. Just pointing out that the current docs (https://symfony.com/doc/current/doctrine.html#main) encourages newcomers to put them in the AppBundle.
I guess that the incredible versatility of SF allows many different work setups, but we should stick to one in the docs and the developer's own experience can evolve from that.

@sh4ka sure it does, as the recommended way in the Symfony doc is to use AppBundle. If the Symfony doc changes its recommendation, we will change the DoctrineBundle doc. The doc still shows how to configure mapping explicitly for people wanting it elsewhere.

@stof that works fine until you want dynamically calculated paths. For KNP Snappy we resolve a path based on the OS (not using images). However, this is simply done in the load method of the extension: $container->prependExtensionConfig('knp_snappy', $snappy_config); and could easily be moved to the kernel if required.

Regarding the class cache, this is simple a set method in the kernel that is being called from a compiler pass. So in theory a custom implementation could be added but is a bit of overhead.

So while all of this is already possible, it's not really clear. In Kernel::prepareContainer all bundles' build method is being called. I was thinking that something like a new build method could add the compiler passes and being called just before the bundle build methods are called. This would also allow a prepend config to be called (ContainerBuilder:"prependExtensionConfig)

// new method in Kernel
protected function build(ContainerBuilder $container)
{
    // register compiler passes in here like in the bundle build method
}

And for the (annotated) class cache Not going to be added, see #20668

// new method in Kernel
protected function getClassesToBeCached()
{
    return array();
}

public function setClassCache(array $classes)
{
    $classes = array_merge($this->getClassesToBeCached(), $classes);
    file_put_contents($this->getCacheDir().'/classes.map', sprintf('<?php return %s;', var_export($classes, true)));
}

This means the kernel will get 3 new extension points:

• protected function build(ContainerBuilder $container);
• protected function getClassesToBeCached()
• protected function getAnnotatedClassesToBeCached()

of course names are up for discussion

I think this would lay a decent foundation for something that might eventually end up as a best practice. Even if it wouldn't, it would give people a decent method to start removing their AppBundle if they wish to.

See #20107

you don't need prependConfiguration at all in the kernel, as you are in the place loading the configuration itself, so you can just load an extra one before the normal call.