Symfony Flex: Paving the Path to a Faster, Better Symfony

Symfony Flex is a modern replacement for the Symfony Installer, and not the name of the next Symfony version. As the intro text says:

Internally, Symfony Flex is a Composer plugin that modifies the behavior of the require and update commands. When installing or updating dependencies in a Flex-enabled application, Symfony can perform tasks before and after the execution of Composer tasks.

The new Symfony will be called just Symfony 4, and while this tutorial will deal only with the Flex tool, it will mention some Symfony 4 upgrades as well.

Still Under Development

Symfony Flex can be considered a Composer wrapper, in that it provides your Symfony project with additional options during installation and configuration. It was developed with simplicity in mind, and obviously heavily influenced by the user-friendliness of Laravel. Remember, Laravel got to its current level of popularity due to its ease of use and the low entry barrier it provides newcomers with, and Symfony wanted to emulate this.

It should be noted that both Flex and Symfony 4 are still under development, slated for release somewhere at the end of November this year (2017). As such, some of the features mentioned in this post may have changed by the time you read it, but we'll do our best to keep it up to date.

Most notably, the use of a makefile and the make tool to build a project if Symfony/Console is unavailable is still up in the air, as it seems to not be working properly on some operating systems. Fabien recently held a survey around this, asking for the community's suggestions to a replacement, and overwhelmingly, the community voted in favor of just making Symfony/Console required.

What's Different?

Most notably, Flex respects the coming Symfony 4 updates which boil down to the following major changes:

• PHP 7+ is required
• all folders are optional. If your project isn't using one, it doesn't have to be there. This makes the directory tree much simpler and more readable. Additionally, often useless files like .htaccess, LICENSE, and README have been removed as well - a project which needs those can easily add them.
• there is no more web folder. Instead, there is the public folder, like in all other major frameworks. This consolidates user experience across ecosystems.
• temporary files go under /var in the root of the project folder, with the /var/cache subfolder reserved for long term cache, like merged class files for deploying apps as read-only artifacts
• source code goes under /src. No /app.
• configuration goes into /config.
• templates go into /templates.
• Flex will have its own Symfony-verified list of packages that are referenced by one and one alias alone. So executing composer require cli will actually trigger Flex, which will look in its list of packages, find the one tagged as cli (in this case, Symfony Console), and install it. These "official" packages are called recipes, and can be found here. To accept user-submitted recipes, a flag exists in Flex's configuration which needs to be set to true: composer config extra.symfony.allow-contrib true. Those recipes can be found here. By officially endorsing some packages, Symfony is in many ways becoming as opinionated as Laravel. While this is bad in some ways, it's very good in many more ways: a consolidated, opinionated way to build Symfony apps used by most people so that everyone is on the same page.
• bundle fragments no longer need to be custom-activated and added into a ton of files. Flex automates this, as well as their removal.
• instead of parameters in config files, Symfony 4 will be using environment variables like Laravel

Bootstrapping

As usual, we'll assume you're already running a healthy VM environment like Homestead Improved so you can follow along.

Okay, let's get our hands dirty with an example app. All Symfony apps can now be started from the bare bones super-minimal Symfony Skeleton app:

 composer create-project symfony/skel

Truncated by Planet PHP, read more at the original (another 2626 bytes)