Symfony 5.3 was released on May 31, 2021. Although we've published many articles about new Symfony 5.3 features, there are some interesting new features that we haven't discussed yet. The first one is the new Runtime Component.
The purpose of the Runtime component is to abstract most of the application bootstrapping logic into so-called runtimes, allowing you to write generic front-controllers. This will make Symfony applications easier to maintain, because the front-controller code can be moved to a Symfony Flex recipe managed automatically by Symfony.
In addition, this component decouples the bootstrapping from any global state to make sure the application can run with runtimes like PHP-FPM, ReactPHP, Swoole, etc. without any changes.
If you open your public/index.php
file, you'll see some code like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
// public/index.php
<?php
use App\Kernel;
use Symfony\Component\Dotenv\Dotenv;
use Symfony\Component\ErrorHandler\Debug;
use Symfony\Component\HttpFoundation\Request;
require dirname(__DIR__).'/vendor/autoload.php';
(new Dotenv())->bootEnv(dirname(__DIR__).'/.env');
if ($_SERVER['APP_DEBUG']) {
umask(0000);
Debug::enable();
}
$kernel = new Kernel($_SERVER['APP_ENV'], (bool) $_SERVER['APP_DEBUG']);
$request = Request::createFromGlobals();
$response = $kernel->handle($request);
$response->send();
$kernel->terminate($request, $response);
In addition to some autoloading and configuration, this file contains the code needed to process the well-known Symfony Request-Response flow. In a new Symfony 5.3 application, the same front-controller uses Symfony Runtime and its code looks as follows:
1 2 3 4 5 6 7 8 9 10
// public/index.php
<?php
use App\Kernel;
require_once dirname(__DIR__).'/vendor/autoload_runtime.php';
return function (array $context) {
return new Kernel($context['APP_ENV'], (bool) $context['APP_DEBUG']);
};
Why is the new front-controller code so concise? Where is the request turned
into a response? What's this autoload_runtime.php
file? Read the new
Runtime component docs to learn about all this and more. You will also
learn how to tweak this runtime and how to create your own runtimes.
If you are upgrading an existing application to Symfony 5.3, you can start using this new component as follows:
- Install the component by running
composer require symfony/runtime
- Update your front controller using the public/index.php code found in Symfony's FrameworkBundle recipe
- Update your console script using the bin/console code found in Symfony's Console recipe
If you want to learn more about this component, join the SymfonyWorld Online 2021 Summer Edition conference (June 17-18, 2021), where Tobias Nyholm will deliver a talk titled "Runtime component: The game changer".
Great one!
Not sure if this is the correct place to ask but here I go.
autoload_runtime.php
is installed by the runtime composer plugin so if I'm deploying to production and I runcomposer install
with the--no-scripts
option the file won't be generated right? Any suggestions on this?Thank you very much
@Gonzalo you are right! Removing "--no-scripts" is exactly what we had to do to use this in production too. I don't know if there's a better alternative.
Thanks Javier. Since I'm running some custom scripts for development I can't remove
--no-scripts
. So I'll be runningcomposer dump-autoload --optimize --no-dev
afterwards ¯_(ツ)_/¯as Gonzalo stated, your need to allow scripts to run to get the autoload_runtime.php created.. which in turn ran all the flex recipes which has screwed my project, as I just converted to all PHP configuration, and now flex has dumped yaml next to the PHP and caused issues with config when building my production containers :( :( :(
Also - Runtime Component is EXPERIMENTAL - this is not made clear in this blog post :-(
If you really want to run with --no-scripts, you can commit the autoload_runtime.php file, it's mostly static!
commit a vendor file is not very intuitive :/
Here you are, this should make things work even with --no-scripts is passed to composer: https://github.com/symfony/recipes/pull/955
It turned out a patch in composer was the best place to fix this behavior! Composer v2.1.2 now still runs plugins (this generates this file) when --no-scripts is passed See https://github.com/composer/composer/pull/9942