The end of the Symfony Standard Edition

When I started to work on Symfony 2 many moons ago, I decided to create a set of decoupled components instead of a monolith framework like symfony 1. This choice was probably one of the key reasons of the immediate success of Symfony 2. I think using dependency injection from day 1 and creating the first dependency injection container in PHP also helped a lot in designing standalone components.

Of course, people don't want to assemble the components themselves when starting a new project. To fill the gap, we created the Symfony Standard Edition. A fast way to get started when creating new projects. An opinionated starting point. "Optimized" for "traditional" frontend applications for which you need a database, a templating system, and a way to send emails.

One of the issues with the Symfony Standard Edition is that even if it makes choices for developers, it comes with either too few or too many dependencies. It does not "scale" well; it is not easy to remove dependencies, and it is not that easy to add new ones.

I won't repeat the many problems with the Standard Edition approach (and other Symfony distributions), as you can read more on my blog, starting with this one.

Suffice to say that the Symfony Standard Edition served us well along the years. But with Symfony 4, it was time to design something new. And Flex was born.

Again, I've written a lot about Flex on my blog. If you are not familiar with Flex, take the time to read my series of posts about it.

Thanks to the new Flex approach, we've decided to not provide the Symfony Standard Edition for Symfony 4.0. But one issue with Flex is that starting projects is more "complex". Most projects need many Symfony features. But new projects now have bare minimum dependencies when created via composer create-project symfony/skeleton. You need to explicitly add all the dependencies you want to depend on. Being explicit is great, but UX suffers.

Thanks to the new unpacking feature of Flex and the new symfony/website-skeleton skeleton, you can now get the best of both worlds.

Like Silex? Start with symfony/skeleton. Like the full-stack Symfony framework better (like what the Standard Edition provides)? Start with symfony/website-skeleton. Then, be free to add or remove dependencies. Scale the way you want your project.

Now that Flex is able to scale up and down very easily, I think it's time to officially announce that the Symfony Standard Edition is now legacy. It should not be a problem for new projects as they should be created with Symfony 3.4 or 4.0, for which Flex is supported. Current projects are not affected in any ways.

Comments

The symfony/website-skeleton was the nail in the coffin for the Standard Edition, thanks for this great tool !
A cool next step would be to create a new "symfony-skeleton" org, and publish all skeletons under that umbrella. Given the new approach, it would probably be something rather low-maintenance, and this would be possible:

composer create-project symfony-skeleton/default
composer create-project symfony-skeleton/website
composer create-project symfony-skeleton/api
composer create-project symfony-skeleton/console
etc
I'm with Davide Borsatto, have some predefined skeleton could be soooo cool. Let's discuss about it in Slack !
The problem I see with flex is the hardcoded recipes for default layout. One step away from it - and you have to reconfigure everything.

Do not use `App` namespace? move all bootstraps, locate and fix every config and file which came with recipe

https://github.com/symfony/recipes/blob/master/doctrine/doctrine-bundle/1.6/config/packages/doctrine.yaml#L25-L26

Modified environments for bundle in bundles.php? get ready to find your app failed

Used skeleton without the framework-bundle? Your console does not work (where is my kernel?)

Used skeleton without the framework-bundle? `composer req profiler` brings files which are not loaded.

Currenty framework bundle recipe IS the new standard edition. It brings the layout, brings the Kernel with all the configs loading system (did I say that if you change it - nothing works?)

The last but not least is a dozens of autogenerated content in projects. For big teams with reviewing process you cannot answer WHY you added new files into project. They were just created. And now we have two lock files...

Sure, quick-starting experience was greatly improved. But at some point flex will be removed from the project, replaced with manual configuration.

And now all the documentation follows the flex ~standard-edition~ framework-bundle recipe layout. All projects upgraded from previous versions to 4.0 will not match it to the current files
Flex is a good move forward! However, I'm still not able to utilize it for in-house software that's never supposed to leave the internal network. This makes Flex useless for me :(
Great news. Btw first thing I did with S4 was dumping the App namespace. Thanks for you great work!
Login with SensioLabsConnect to post a comment