For the past few months, Numendo’s developers have been able to discover and test the new features of Symfony 4, the famous PHP framework made in France. At present, the stable version is 4.1, and 4.2 should become stable at the end of this year.
What does Symfony 4 actually offer?
Symfony was created to make developers’ lives easier by sparing them repetitive, tedious tasks and thereby helping them to focus on the application itself, rather than on the technical difficulties that building a web application from scratch can involve.
That was already the case in previous versions of the framework. With version 4, SensioLabs goes even further by developing essential features that were missing in previous versions and by simplifying the project structure while adapting to industry best practices.
SensioLabs encourages Symfony 4 users to stop breaking their applications down into bundles. Using the single App namespace for an entire application makes it possible to avoid falling into complexity with AppBundle, UserBundle, ProductBundle and so on. We can therefore organise our project directly in the src folder.
Along the same lines, we can see the appearance at the root of the project of the assets, templates and translations folders, which are the folders for our application’s main resources. The public folder (formerly web), for its part, contains only the index.php file, which, thanks to the APP_ENV environment variable, will display the dev or the prod version.
When we talk about new versions of a framework, we always have in mind the difficulty of migrating from a previous version to the current one. There is no miracle solution: depending on your application’s Symfony version, it will be more or less difficult. But if you developed your application with version 3.4 without using deprecated features or components, that will save you from having to recode certain parts that have become obsolete.
If you are not very familiar with the Symfony 4 structure, the simplest thing is to create a new Symfony 4 project, add the components used in composer.json and place your files in the right locations, taking care to correct the namespaces, the routes and the links to templates and other assets.
This can be worth it if you are still in the middle of development and certain features interest you. Be careful, however: Symfony version 3.4 benefits from support (bug fixes) until November 2020, whereas version 4.1 benefits from it only until January 2019. This means you will have to maintain your application regularly until the “long term support” version. What’s more, if you have significant stability and security requirements, staying on Symfony 3.4 is the wisest choice for now.
You have two options when you start a Symfony 4 project: the first allows you to start with everything you need in order to create a web application; the second, much lighter, allows you to start a micro-application with the bare minimum, without anything superfluous. This solution is suited to creating micro-services, which don’t necessarily need Twig or the WebProfiler, for example. Installing and configuring the components useful to your micro-application is simplified thanks to Symfony Flex.
The new features that caught our attention
Symfony Flex
Flex is a Composer plugin that makes it possible to install your components directly in your application. No more loading them into Symfony by hand, thanks to the use of Recipes. They make it possible to define which files are to be created, copied or ignored (.gitignore), and which commands are to be run after installation. The community is very active and many recipes are available.
Internationalisation of routes
In version 3.4, you had to install a third-party component to handle URL internationalisation, or make do with a simple locale in the URL to be defined on each route. With Symfony 4, we can define a language prefix in a general way for our URLs, or even completely different URLs from one language to another. Here is an example of an annotation-type configuration:
A CodePen embed (“WyMgoo” by Aaron, @leox47) showed this configuration example in the French version and needs to be re-attached.
Simple as that!
Managing assets with Encore
Symfony 4 includes asset management with Webpack, thanks to Encore. Encore is billed as a mix between Webpack and Mix. Among other things, it makes it possible to simplify the configuration of our webpack.config.js file. Need to precompile SASS or TypeScript? Need to configure a CDN? All that is done in a few lines!
A CodePen embed (“GGxpaL” by Aaron, @leox47) showed this configuration example in the French version and needs to be re-attached.
But Encore’s main advantage is that it can be integrated into the Symfony environment. Among other things, it makes it possible to load only certain assets according to the routes defined in your controllers. For example, you can load only the styles and scripts of the public part of your application on that part, while also managing the assets of a private part and of a back office. Since integrating the scripts into Twig is done very easily, this allows for a fairly effective workflow.
The modules are installed using npm, or even more simply via yarn. You can easily launch a build of your dev and prod configuration.
Unfortunately, it couldn’t be perfect! It is version 3 of Webpack, and not version 4, that is used with Encore, for reasons of compatibility with projects running Webpack 2 and 3. If you want to use the new features of Webpack 4, move along for now and install Webpack 4 independently of Symfony.
So, are you ready to use Symfony?
We recommend you get started with it quickly if you haven’t already. Symfony version 4 for your new projects is a very low-risk bet. If you know Symfony, it will be easy to work on this new version, and if you want to learn, the learning curve promises to be much less steep given SensioLabs’s determination to adapt this PHP framework to current best practices in terms of web application development.
Your projects will gain in lifespan and in simplicity, your development work will be more efficient and more profitable, and migrating to the “long term support” version will be much simpler than if you had started from a project running Symfony 3.4.
We also offer several articles related to other frameworks and to PHP on our blog — don’t hesitate to take a look.
