Symfony 4 – szybki przegląd

Symfony 4 zostało wydane zgodnie z zapowiedziami 30 listopada. Z racji, że miałem okazję na szybko wdrożyć bardzo mały projekcik przy użyciu sf4, postaram się przedstawić zmiany, które rzuciły mi się w oczy.

Podstawowa wersja

W poprzedniej wersji symfony przy instalacji domyślnie mieliśmy wiele paczek, z których nie korzystaliśmy. Zaczynając projekt trzeba było je usuwać. Przykładowo po co nam Twig jeśli tworzymy tylko i wyłącznie API. Takie podejście nie jest niczym dobrym, wymaga od nas dodatkowych nakładów pracy przy usuwaniu niepotrzebnych elementów, a jeśli je zostawiamy to wprowadzamy w projekcie nieporządek.

W Symfony  4 dostajemy tylko podstawowe paczki, wszystko czego potrzebujemy dodatkowo np. twig, doctrine musimy sami doinstalować. Podstawowe zależności prezentują się następująco:

"require": {
    "php": "^7.1.3",
    "symfony/console": "^4.0",
    "symfony/flex": "^1.0",
    "symfony/framework-bundle": "^4.0",
    "symfony/lts": "^[email protected]",
    "symfony/yaml": "^4.0"
},

Symfony Flex

W poprzedniej wersji symfony sama instalacja dodatkowego bundla przez composera nie wystarczyła, trzeba było dodać go do Kernela i utworzyć odpowiednią konfigurację.

Narzędzie Symfony Flex pozwala na zautomatyzowanie procesów instalacji oraz dezinstalacji bundli, wystarczy wydać polecenie np. composer req doctrine, a Flex doda również odpowiednią konfigurację. Pliki konfiguracyjne dla dodatkowych paczek znajdują się w osobnych plikach w katalogu config/packages. Jeśli potrzebna jest konfiguracja w pliku, w którym są również dane od innej paczki są one odpowiednio rozdzielane, tak, aby narzędzie wiedziało co usunąć przy dezinstalacji.

###> symfony/framework-bundle ###
APP_ENV=dev
APP_SECRET=307fbdc5fd538f6d733e8a2f773b6a39
###< symfony/framework-bundle ###

###> doctrine/doctrine-bundle ###
# Format described at http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/configuration.html#connecting-using-a-url
# For an SQLite database, use: "sqlite:///%kernel.project_dir%/var/data.db"
# Configure your db driver and server_version in config/packages/doctrine.yaml
DATABASE_URL=mysql://db_user:db_passwor[email protected]:3306/db_name
###< doctrine/doctrine-bundle ###

Flex korzysta z tak zwanych przepisów (recipes), gdzie pliki konfiguracyjne określają jak ma się zachować przy instalacji danego pakietu. Przykładowo dla doctrine wygląda to tak:

{
    "bundles": {
        "Doctrine\\Bundle\\DoctrineBundle\\DoctrineBundle": ["all"]
    },
    "copy-from-recipe": {
        "config/": "%CONFIG_DIR%/",
        "src/": "%SRC_DIR%/"
    },
    "env": {
        "#1": "Format described at http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/configuration.html#connecting-using-a-url",
        "#2": "For an SQLite database, use: \"sqlite:///%kernel.project_dir%/var/data.db\"",
        "#3": "Configure your db driver and server_version in config/packages/doctrine.yaml",
        "DATABASE_URL": "mysql://db_user:[email protected]:3306/db_name"
    }
}

Flex odpowiednio:

• dodaje DoctrineBundle do pliku config/bundles.php
• kopiuje pliki z przepisu do odpowiednich katalogów projektu
• dodaje następujące dane do pliku .env, oznaczając z jakiego bundla pochodzą te dane

Narzędzie do kontroli zmian zależności w projekcie wykorzystuje plik symfony. lock w stylu composer.lock, w którym zapisywane są dane jaki recipe został wykorzystany, jaka wersja itp.

Brak bundli

W Symfony 3 mogliśmy tworzyć bundle w katalogu /src, jednak przez wiele osób było to źle wykorzystywane. Bundle powinien być niezależny od reszty aplikacji, tak aby można go było zastosować bez problemu w innym projekcie. Jednak często stosowano podział na bundle, które ze sobą były ściśle powiązane, co było nieprawidłowym ich wykorzystywaniem.

W Symfony 4 nie mamy już podziału na bundle, co powinno zmniejszać złożoność projektów. Cały kod aplikacji powinien znajdować się po prostu w katalogu src/ i przestrzeni nazw App\.

Environment

W Symfony 3 szczególnie przy odpalaniu komend na produkcji trzeba było pamiętać o dodawaniu –env=prod, bo domyślnie każda z nich odpalana jest w trybie dev.

Obecnie ustawiamy ENV=prod w pliku .env i mamy spokój.

Podsumowanie

Uważam za duży plus zmianę odnośnie tworzenia nowego projektu i zarządzania zależnościami. Powinno być teraz dużo łatwiej ogarnąć chaos związany z bundlami oraz ich konfiguracją.

frameworkphpsymfony