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/skeleton flexy

Notice the created directory structure.

In /public, we no longer have app.php and app_dev.php, only the index.php file. The type of the environment (test / dev / prod) is now dictated with environment variables, and reads the configuration from the /config folder.

Notice how the end of the installation process mentions that make cache-warmup was called, and that you can run make serve. This is where the new Symfony uses the "controversial" Makefile approach mentioned above. This might change.

Out of the box, opening this skeleton in the browser will throw an error because no routes have been defined yet. Let's fix this.

index:
    path: /
    defaults: { _controller: 'App\Controller\DefaultController::index' }

config/routes.yaml

We'll need to create this controller and its index action:

<?php

namespace App\Controller;
use Symfony\Component\HttpFoundation\Response;

class DefaultController
{
    public function index()
    {
        return new Response('Hello');
    }
}

This will produce a simple Hello screen, like so:

Execution Permissions

If you try to install a binary like the Symfony/Console with composer req cli, you might run into the following problem:

~ bin/console
-bash: bin/console: Permission denied

This is a known hiccup when using virtual machines, and can be easily fixed by either:

• running the console with php bin/console instead of running it directly, or
• adding the "execute" permission to the file on the host machine (not from within the virtual machine), by executing: chmod +x bin/console. This will allow the direct execution of bin/console from within the VM then.

Continue reading %Symfony Flex: Paving the Path to a Faster, Better Symfony%