Symfony Flex: A new RAD way for Symfony

Symfony Flex: A new RAD way for Symfony

Tired of starting your Symfony projects with the same boring tasks? Requiring bundle by composer, enabling it in AppKernel, then configuring in config.yml? I’ve got good news for you. This will all be possible very, very soon! Symfony 4 will feature a completely new approach to building applications. Let’s talk about Symfony Flex!

What is Symfony flex?

Symfony Flex is new composer plugin for Symfony. Its task is to simplify the process of building applications with bundles that closely fit your demands. The goal of the Symfony team was to achieve two things:

  • Simplify installing dependencies in a project
  • Help use only those functionalities (from Symfony or other projects) which are really needed (no unused ones)

Symfony Flex does the first job well. The second one is achieved by Symfony dependency repositories, called recipes, which I’ll describe later. Here’s what happens when you want to install a new dependency: it first searches if there’s one that fits your requirements in Symfony recipes. If it’s indeed there, it follows the included instructions. It follows all the steps we needed to take earlier, however, it does so automatically, with default configuration. Simple and ready to use.

Symfony roadmap

Building an application with Symfony Flex will be the default mode, and the only correct approach from Symfony 4.0 onwards. But you can use Symfony Flex with Symfony 3.3, which was just released. Until the next major version is released, you should consider it alpha software. For a full roadmap, you can take a look at this Symfony doc.

Symfony recipes – core and contribution-based one

You might say: “OK, it’s cool that Flex can automatically download and configure my dependencies, but where does it get them from?” The answer is Symfony recipes. There are two Symfony repositories called recipes:

What’s the difference between them? In the first one, every package will be thoroughly investigated by the Symfony team before it’s accepted. In the second one, adding packages will be much easier (passing tests will be enough, most of the time).

Main advantages and disadvantages of the new approach.

As every big change, it has both advantages and drawbacks. I’ll try to describe the ones I’ve noticed.


  • Easy installation and uninstallation of packages. Some of them (like Symfony Requirements) are very useful to have for some time, just to check if everything is ok. After that, this component is redundant, so we can remove it.
  • Autoconfiguration. When working with a new bundle, most of the time you start with some default configuration to check if it works correctly and then adjust it to your needs. Now, the first step is already done. You must only customize it if needed.
  • Cleaner documentation. The docs will no longer have boring and repetitive configuration instructions.
  • Choices made by experts. Let’s say I need an API in my project. ‘Till now I’ve needed to search for suitable bundles, and in cases when there were more than one I couldn’t predict which one would be the best. Now, I can rely on the Symfony team’s decisions, – they know which of the available bundles work best as they’ve reviewed them.
  • Decoupling. Let’s say I don’t need the Symfony webserver, because I’ve been using Apache from the very beginning. For Symfony 4 and Flex, they decoupled the Symfony core. For a default option, the project needs only “symfony/framework-bundle” and “symfony/flex”. All others are optional.


  • Using Flex requires a new project structure. You no longer have e.g. AppKernel and config.yml files. You have to perform this step anyway when you’ll be upgrading to Symfony 4.0, but still.
  • At first glance, there is some automagic here, but only for the beginning. Everything works due to composer hooks and a slightly altered structure of a Symfony project.

Short example

To show you what a great experience using Symfony Flex is, let’s use a short example.

Hmm… What can we do? Maybe some API use case?

Be serious, everyone can do that (if not, you should look this screencast).

No, let’s build something more fabulous, like… a cat thumbnail generator! That’s the thing! Everyone likes cats, right? Let’s assume we have a few images of cats in different resolutions. When someone goes to our webpage, we would display one of them in square size. Let’s start the project from this bare minimum:

To have a better understanding of what we’re doing here I strongly recommend reading up on Symfony 4’s new directory structure and best practices.

For our project, we’re going to need a webserver and something which can create our miniatures (in time will be the best option). That cool bundle is LiipImagineBundle. It’s already in the symfony/recipes-contrib repository. To enable Symfony Flex searching in contrib recipes as well, you should change “allow-contrib” parameters in composer.json from false to true.

Depending on the version you are using, after requiring liip/imagine-bundle you might have to fix no issue: move “locale” parameter from services to parameters in containers.yml. As I said, it’s still in alpha and I encountered this issue when I upgraded Symfony from RC to the 3.3 stable one.

Now, install the dependencies. When running composer req it informs you also to uncomment liip config, just to that. The other cool things in Flex are aliases. As you can see, I don’t need to type symfony/web-server-bundle, server is enough (more here). I created an image folder in the web directory and put a few cat images there. These are: cat1.jpg, cat2.jpg, cat3.jpg. Now we should add Controller and action to it.

At this point, we just need to add routing and we’ll be ready to go:

Now just type make serve (Symfony user Makefile commands now) and check enter your browser to check if everything’s working. Isn’t that fast?

You can download the full example from here.


Symfony Flex changes the way of building projects and shortens our decisions about which dependencies we want. I consider it a very good step forward in developing projects in Symfony (something we do pretty often around here!). I’m really looking forward to using it on production – along with Symfony 4.