Now includes updated versions of:

• [DI] Add getter injection symfony#20973
• [DI] Getter autowiring symfony#21031
• [FrameworkBundle] Introduce autowirable ControllerTrait symfony#18193
• ActionBundle

It's ready to test.

I really like the idea of Bundleless symfony applications but with this structure how we should register some features like :

• compilerPass, I usually put them inAppBundle::build method
• custom configuration : aConfiguration class is put inDependencInjection directroy and used in theAppExtension class where the config is computed and injected in the container (for custom parameters for example)

thanks

custom configuration : a Configuration class is put in DependencInjection directroy and used in the AppExtension class where the config is computed and injected in the container (for custom parameters for example)

if you need a semantic configuration, you will need a bundle (well, technically, you need a DI extension, but adding one without a bundle becomes painful even though it is possible, as non-bundle extensions are called only when they have some config explicitly)

compilerPass, I usually put them in AppBundle::build method

you can overrideKernel::prepareContainer to register additional compiler passes (don't forget to start with aparent call, otherwise you will break any bundle-provided DI features)

I personally agree with all the goals of 3.3 (it took me some time to be ok with some of them though, but here we are).
However, I do think bundles are a great feature that is imo not something hard to understand when starting to use symfony (as opposed to the container and all related stuff), even more, it gives an idea of what is separation of concerns and a good opportunity to start applying it for then, when becoming pretty comfortable with symfony, start moving stuff outside of bundles.
Nobody forces you to use bundles as well as nobody forces you to use autowiring, but you can at least find an example of this great concept and start playing with it as you wish thanks to theAppBundle. Manipulating bundles in its own app also makes easy to understand how to manipulate and write 3rd party ones, thus reuse instead of reinvent.
So, do we really want to remove the concept of bundles from the default structure?

(It's just a question, do not see any offence, I do love bundle-less apps, but only after having used bundles for years since these ones given me a structured way to organize my code and, I fairly trust it, helped to make me a better developer)

Hello folks,

I love this PR but I also have a question related to my freelance position with lot of legacy-to-(symfony|microkernel|silex) projects. If there is no more AppBundle and the "best practices" encourage us to add our configuration, views, etc inapp, why you don’t simply movesrc toapp/src ?

There is (at least) three advantages to do this for DX and/or project :

• I know a lot of people hate this but (even if I don’t like it too), renaming the app folder and add another one for multi-app (ok you will have problems withScriptHandler but multi-app is not standard so...)
• For monolithic projects, add your frontend application (vue.js for example but it works with a lot of things) aside to your backend application
• If an application is growing up : cut/paste/done.

And for@chalasr because his question is a true one, rename the actualsrctobundle could be an answer.

And again, I love this PR :D

The goal of this PR is to experiment with automatic service registration and bundle less apps. However the final target is Symfony Flex (it's why this PR has the[do not merge] flag). Let's see what it looks like first.

I've updated this PR to use new features of 3.3 instead of ActionBundle:

• no more AppBundle
• controllers and commands are automatically discovered and registered as services
• controllers and commands are autowired, you can typehint any class in their constructors and use it as a service without having to register it manually (tldr: to create a new service: create a class somewhere insrc, typehint it in your constructor or anywhere else, it will be automatically instantiated and injected)
• for newcomers and performance sensitive apps, theControllerTrait can be used to automatically inject common services (same as the currentController class) through getter injection. This feature is not mandatory (if you want to cherry-pick deps of your controller, just typehint services you need in its constructor) but is a shortcut for newcomers showing all the power of Symfony (common features).

I've also updated the directory (just a proposal):

• conf/: config files
  • dev/: conf overriding for thedev env
  • prod/: conf overriding for theprod env
  • test/: conf overriding for thetest env
• src/: all PHP code (including the kernel)
  • no moreAppBundle
  • Controller/: Controllers
• templates/: Twig templates (can be removed if you don't use Twig - e.g. API Platform)

Unchanged:

• bin/
• var/
• vendor/
• tests/
• web/

Nice! I have a question: Why not doconfig/ instead ofconf/?

@ruudk It's shorter and maybe more common, but I've nothing againstconfig.

@dunglas As you are breaking everything, could we broke also:
app/Resources/views/base.html.twig → templates/base.html.twig toapp/Resources/views/base.html.twig → templates/layout.html.twig (base->layout) ?

@dunglas really interesting, this also need a MASSIVE update of docs and probably a new "Best practices" standard or all apps will become a mess ^^

Is this intended to replace the actual Symfony full edition? Or is Symfony flex a new "edition"?

@mickaelandrieu it's just a personal experiment for now, nothing official (it's why the PR title contains[do not merge].

@lyrixx done

Where does your ressources directory will go with this structure ? (translations / assets / ...)

EDIT : Imo it should be a directory insidesrc/ but maybe it should be explicitely set to show the best practice about this ?

According to the new structure (purposed) the configuration path should be

public function registerContainerConfiguration(LoaderInterface $loader){    $loader->load($this->getRootDir().'/../conf/'.$this->getEnvironment().'/config.yml');}

(i.e./conf/dev/config.yml)

https://github.com/symfony/symfony-standard/pull/1034/files#diff-aa0dbf36ede817d01f5be6f15d867bb4R65

I already use quite the same architecture in my projects (as far as the current Symfony release allow me to go). I will be pleased to see Symfony go this way.

@mnapoli IMHO views and config are not resources. Views are almost sources and config, well it's config. It won't bother me to have a translations folder at the same level assrc/.

@maximecolin,@mnapoli : IMHO views and configs are considered resources in a PHP project, as soon as it needs to be located and is consumed by your app.
I actually like theres folder convention, and given the changes done in this PR, I'll find natural to find config, views, translations (,...) in it.

What's also to consider in this change of putting all resources together (and then I'll stop talking about it) is that it's a first step towards universal resource location (which is actually Puli's goal).

Everything insrc/ can be loaded/autoloaded using PSR-4. For the rest, ares/ folder could maybe enable a standard in resource location? Just throwing that idea in there :)

And to add my brick in the wall, ares/ folder could be shared between different services and loaded via resource locators in different ways, like Puli proposes 😏

@Pierstoval Puli is a great tool but we have to be careful. The project is not very active, it is still in beta, it is much more than a Resource Locator and, unless this has changed, Puli is not yet compatible with Twig 2.x.

So two options, create a Resource Locatorà la Puli or contribute to the project.

BTW, I ❤️ Puli and this PR too.

is there any way to get rid ofconf/autoload.php? doesn't feel like the the right place. Would be nice if composer could handle the annotation registry registration automatically.

@jrobeson Good point.

My current directory structure for a single app :

@ogizanagi Ok, I see what you mean. I'm just quite not confortable with the idea views are not code sources in the same way php files are. But it make more sens with this definition of resources.

@dunglas what things like typescript, less, javascript etc, things that need pre-processing? Currently I useapp/Resources/assets, but this feels wrong.

I have been using the following structure lately and quite like it:

.├── bin├── config├── etc├── resources│   ├── assets│   │   ├── images│   │   ├── js│   │   └── sass│   ├── fixtures│   ├── migrations│   ├── translations│   └── views├── src│   ├── AppCache.php│   ├── AppKernel.php│   └── autoload.php├── var├── vendor└── web

Whats the etc about? Docker and build-stuff?

@sstok yeah, anything that doesn't really fit in the other dirs

is there any way to get rid of conf/autoload.php? doesn't feel like the the right place. Would be nice if composer could handle the annotation registry registration automatically.

@jrobeson seesymfony/symfony#21837 which is working on it.

Just an idea: can't the "action edition" become a new official Symfony edition instead of replacing the Standard Edition?

Symfony CMF already makes updates to his full-stack application from time to time, all based on standard edition, and they seem to agree with it (or maybe it's just me who thinks this 😛 ).

I mean, it has been a bit discussed that the installer could install different Symfony distributions than Demo and Standard Edition (see symfony/symfony-installer#39 ), but actually, the "action pattern" one could easily be one of the different editions.

And it could engage the development process in the installer & the Symfony team on"How to define a Symfony edition", etc.

Obviously, more editions = more maintenance, but as the "action" one will start with Symfony 3.3, this is less maintenance than the SE 😆

@Pierstoval having multiple official editions has a huge impact on the documentation. So I would not make it an official extension today, especially given that this PR is clearly experimental currently (and relies on unmerged Symfony PRs).
The big maintenance overhead of adding a new edition is not in the installer (where we could easily add support for another one) or in the distribution channel (the building of the SE archive is automated, so this could probably be reused). It is in the need to maintain the documentation twice due to different ways to structure the project.

I partially agree, especially about the fact that there is an impact on the documentation.

But actually, a new Symfony edition is maintained by its maintainers, and so should be its documentation, what do you think?

Symfony Distributions are dead. They won't exist in Symfony 4. We won't need them anymore. This will be replaced with Symfony Flex instead. I really have to blog about that as not everybody was at SymfonyCon in Berlin. Will try to do that ASAP to give more background.

Symfony Distributions are dead. They won't exist in Symfony 4.

That's great news! 👍

I really have to blog about that as not everybody was at SymfonyCon in Berlin. Will try to do that ASAP to give more background.

would be great, especially as there is nothing about your keynote available AFAIK: no slides, no video (last time I checked).

Closing this one. Flex is on its way now :)

So you're confident that Flex will resolve all of these issues, and that everyone will embrace it? 😄