Can we make route definitions available?

@ro0NL you mean configuring them ?
That's not possible as the routing component is build around resources that must be loaded at the root of the project.

Yes, as a resource. A bit like the theMicroKernelTrait does (ref).

edit: this is somewhat related to#19594 using the kernel as a service (hence a route resource)

@ro0NL the kernel is the root of the project, a bundle isn't.

Understand, im talking about registering (mounting)bundle:SomeBundleName:loadRoutes from thekernel:loadRoutes resource. Imagine a micro kernel, built from micro bundles.

This is possible in the micro kernel trait because the kernel is also a service but bundles aren't and i don't think they should be.
I understand your motivation but it would create weird cases (what about prefix, etc when loading bundles routing?).

Asusual?

// AppKernel::loadRoutes$bundleRoutes =$loader->import('bundle:SomeBundle:getRoutes','service');// getRoutes to clarify$bundleRoutes->addPrefix('/some-bundle');

I understand this is not as easy (kernel is a service like you mentioned). However for me, having the kernel as a service is just as weird as having a bundle as a service. Hence i want to propose separating this (kernel/bundle in the ecosystem vs. kernel/bundle as a service).

@ro0NL ok got it, you would like to be able to use the bundle class as a resource.
Well I'm not especially against that but I don't how it should be done and adding such support is out of the scope of this PR. We'll still be able to add such support later, this PR is already proposing a huge change as is.

@ro0NL Does this bundle solve your use-casehttps://github.com/rollerworks/RouteAutowiringBundle?

Edit. Hmm, you want to define routes as a service completely? It should be possible, but you would have to register the Bundle class as a service which seems like a terrible idea 😉

Or you need to create a complete route service definition, which is not easy I know of experience 💀

The main advantage of MicroBundle I see is the removal is Extension class.
I have seen projects with a simple Extension class to load only simple XML services file 😝

I guess for now i would workaround using the kernel as a service, which couples perhaps better anyway.

// SomeBundlepublicfunctiongetRoutes() {returnnewRouteCollection(/*...*/);}// KernelpublicfunctionloadRoutes(LoaderInterface$loader) {$bundleRoutes =$loader->import('kernel:getSomeBundleRoutes','service');$bundleRoutes->addPrefix('/some-bundle');}publicfunctiongetSomeBundleRoutes() {return$this->getBundle('Some')->getRoutes();}

Im not even sure it's supported though... importing routes from a service?

Would such feature be accepted?

Imo it should be, as it's the missing part of the micro kernel right now.

I don't really understand why this is useful in the context of a micro-*. The application using the MicroKernelTrait should probably be bundle-less. What's the benefit or introducing a Bundle in such cases?

@fabpot that's useful for tests for the micro kernel but it is mostly useful for most small bundles that doesn't need a complex structure.

Sorry, I wasn't clear in my previous comment. I'm not saying that this is not simpler that the default Bundle class; I just think you don't need a bundle at all.

@fabpot i understand but i don't think micro apps are the biggest target here.
This micro bundle can be used for small third party bundles that don't need a big configuration/extension.
It may also be used to explain to newcomers the extension system (knowing a class FQCN is simpler that an entire folder structure, and it is also easier to understand).

I think that the extension system should never be used for anything but Open-Source/shared bundles. In which case, there is no need for something simpler. In any case, naming it like MicroKernel as one might think that there are related, but they are not.

@fabpot why wouldn't we need something simpler? An extension may only contain services loading with maybe a few configuration parameters to manage and in this case it looks overkill to have 3 classes to do that.

The application using the MicroKernelTrait should probably be bundle-less.

Disagree, i truly consider a micro app built from simple bundles.

What's the benefit or introducing a Bundle in such cases?

Separation of concerns and reuseability.

In any case, naming it like MicroKernel as one might think that there are related, but they are not.

They are :) In the sense that a kernel can load bundles. However naming it micro could cause users to think it'srequired to have micro bundles, when using a micro kernel. Which indeed is not the case.

Maybe we can do better naming...SimpleBundle?

edit:
As this easily can be done in user-land it could be a reason to not ship it with the core framework. Totally legit... but that also counted for the micro kernel trait. Hence i think at this point it should be shipped for the same reason. And eventually they play well together 👍

@ro0NL thanks for your reviews, I fixed your last comments :)

The last version injects a loader inSimpleBundle::load() which allows to have something even lighter:

class AppBundleextends SimpleBundle{protectedfunctionload(array$config,ContainerBuilder$container,LoaderInterface$loader)    {// Loads a directory$loader->load('store');// Loads a single file$loader->load('basket.yml');    }}

For now the path toResources/config is hardcoded but I'd like to create a new method inSimpleBundle allowing to customize it. I just don't know what to call it...

SimpleBundle::__construct?

We could also consider$loader->load('Resources/config/store'); and keep things simple :)

@ro0NL in the constructor? I was thinking about a protected getter.

Keeping things verbose work as well but it's not very friendly when you have a lot of files to load. Letting the user choose the paths he wants to use is better imo.

Yeah.. like__construct($loaderPath = 'Resources/config'). And override it if you load a special bundle :)

This path is usually user-defined (as symfony is flexible).. not sure introducing some special new path (i cant think of name either..getConfigPath?) is the right way. Thats why i prefer$loader->load('whatever/bundle/path') as it keep things tight to the user. Opposed to having it tight to the bundle's definition.

@GuilhemN given PHPArray file config doesnt come to core, and this is practically a big self-bridging class... im :-+0: i guess. It gave some good ideas for smaller apps though 👍

@ro0NL why would we need to update the config in a bundle ? A bundle should only configure services/parameters.

You dont :) I really like the combination of it all in that sense; for having smaller apps and bundles. Basically the whole philosophy on it's lowest level. Not ending up with a big fat dir. structure and fancy config :)

Still 👎 on adding this in core. ping @symfony/deciders

I'm also 👎

The argument a single class is simpler doesn't convince me. Number of classes is not necessarily and indicator of complexity. What worries me with the "SimpleBundle" is that it mixes several responsibilities and can quickly get out of hand. I also think it's better to have one way of doing things.

Btw, if you insist on having everything in a single place perhaps anonymous classes could be helpful.

Thus, this PR still wants to support all features available with an extension, but puts them all in the bundle class. This does not make any sense IMO. If you want to process configuration, define the appropriate classes