Symfony support

1. Project files
2. Project directory
3. Cache

Examples of Symfony applications can be found in the project under fixtures/build/dir012 (Symfony5) and fixtures/build/dir018 (Symfony6 with the Runtime component).

They may slightly vary to what you want to do since they are here for testing purposes, but they should be good enough to show-case a working scenario if this doc does not prove to be enough.

Project files

When working with a Symfony project, you usually have a few files that are necessary for the application to work but cannot be inferred from Composer. A non-exhaustive list: .env, public, config, var.

As a result, you will likely need to add them via directories, files or their *-bin variant which may force you to use the force-autodiscovery setting. For more information you can find check the Including files doc.

Project directory

Symfony 5.1+ defines the "project dir" as the directory where the composer.json file is. Because box deletes it during PHAR compilation, you need to redefine it in your Kernel. It is usually located in src/Kernel.php and can be defined as follow:

<?php

class Kernel extends BaseKernel
{
...
    public function getProjectDir()
    {
        return __DIR__.'/../';
    }
}

Cache

What makes Symfony a bit special for shipping it into a PHAR is its compilation step. Indeed, the Symfony container can be dumped depending on multiple parameters such the application environment, whether it is in debug mode or not and if the cache is fresh.

A PHAR however is a readonly only environment, which means the container cannot be dumped once inside the PHAR. To prevent the issue, you need to make sure of the following:

• The cache is warmed up before being shipped within the PHAR
• The application within the PHAR is running in production mode

To achieve this with the least amount of changes is to:

• Create the .env.local.php file by running the following command:

composer dump-env prod

This will ensure when loading the variables that your application is in production mode.

• Change the following part of the composer.json file:

"scripts": {
    "auto-scripts": {
        "cache:clear": "symfony-cmd",
        "assets:install %PUBLIC_DIR%": "symfony-cmd"
    },
    "post-install-cmd": [
        "[@auto-scripts](https://github.com/auto-scripts)"
    ],
    "post-update-cmd": [
        "[@auto-scripts](https://github.com/auto-scripts)"
    ]
},

For:

"scripts": {
    "auto-scripts": {
        "cache:clear": "symfony-cmd"
    },
    "post-autoload-dump": [
        "[@auto-scripts](https://github.com/auto-scripts)"
    ]
},

I.e.:

• You skip the installation of assets (which you shouldn't need in the context of a CLI application)
• Trigger the auto-scripts, which includes the cache warming phase, on the Composer dump-autoload event

This last part takes advantage of Box dumping the autoloader by default.

« Docker support • Reproducible build »