Dzień 30 listopada 2017 r. w świecie PHP obfitował w nowości. Uaktualniono wersję języka PHP do 7.2, wprowadzając nowe funkcjonalności oraz poprawiono wykryte błędy. Szczegółowy wykaz zmian można znaleźć tutaj.
SensioLabs natomiast wypuściło całkowicie nową wersję Symfony o numerze 4 oraz uaktualniło poprzednią wersję frameworka do wersji 3.4, nadając jej status LTS (Long Term Support) ze wsparciem do listopada 2020 r., tym samym zamykając rozwój frameworka w wersji trzeciej.
Skupmy się jednak na Symfony 4, zapowiadanej przez Fabiena Potenciera na swoim blogu jako „Nowy sposób tworzenia aplikacji internetowych”.
Co nowego w Symfony 4
Koniec z Bundlami
Symfony 4 jest aplikacją bundle-less, co oznacza, że od tej wersji frameworka zrywamy z ideą bundli znaną z poprzednich wersji. Jako best practices zalaca się użycie App jako namespace dla każdej klasy w katalogu src/.
Co z bundlami od dostawców zewnętrznych?
Domyślnie zarządzanie bundlami jest teraz obsługiwane przez Symfony Flex, o którym powiem więcej w dalszej części artykułu. W wersji 4 oraz 3.4, Symfony, wymaga aby bundle posiadały odpowiednią strukturę katalogów i plików w celu automatycznej konfiguracji podczas instalacji. Jeśli jednak Twój bundle wymaga specyficznej konfiguracji post-instalacyjnej należy utworzyć Symfony Flex Recipe (https://github.com/symfony/recipes).
Co jeśli bundle, którego używasz nie posiada stosownego pliku recipe?
Symfony Flex w dalszym ciągu będzie potrafił zarejestrować bundle, jednak konfiguracja pozostanie po Twojej stronie. Jeśli znajdziesz taki bundle, możesz zgłosić chęć kontrybucji poprzez Pull Request do symfony/recipies-contrib.
Listę wszystkich plików recipe znajdziesz na Symfony Recipes Server.
Symfony Flex
Symfony Flex to nowy sposób na zarządzanie aplikacjami zbudowanymi na bazie Symfony. Flex automatyzuje większość zadań podczas pracy z Symfony 4, jak na przykład instalację i usuwanie bundli oraz zarządzanie zależnościami Composera. Symfony Flex to plugin do Composera który modyfikuje zachowanie komend require, update i remove.
Prześledzmy poniższy przykład aby zobaczyć jak działa Flex.
$: cd my-symfony-project/ $: composer require mailer
Jeśli wykonamy powyższą komendę w aplikacji, która nie używa Flexa, Composer zwróci błąd z informacją że pakiet „mailer” nie istnieje w repozytorium.
Domyślnym repozytorium Composera jest Packagist i faktycznie, próżno tam szukać pakietu o nazwie „mailer”, szczególnie że wymogiem Packagist jest aby nazwy pakietów składały się z dwóch członów: nazwy dystrybutora i nazwy pakietu.
Natomiast jeśli wydamy tę samą komendę wewnątrz aplikacji z zainstalowanym Symfony Flex, zostanie zainstalowany i włączony SwiftmailerBundle (alias: mailer), który jest oficjalnym komponentem zarządzającym e-mailami.
Dlaczego tak się dzieje?
Flex w pierwszej kolejności wysyła żądanie do Symfony Flex Server, jeśli nie znajdzie tam żądanego pakietu, przechodzi do zwykłej procedury bazując na Composerze i wysyła żądanie do Packagist. Jeśli jednak znajdzie żądany pakiet na serwerze, Flex zwróci plik zwany „recipe” (ang. przepis), bazując na nim przeprowadzi instalację oraz automatyczną konfigurację.
Podobnie jak Composer trzyma informację o zainstalowanych zależnościach w pliku composer.lock, tak Symfony Flex trzyma informację o zależnościach w pliku symfony.lock, który wraz z kodem powinien być trzymany w repozytorium.
Mikroframework
Symfony 4 zaraz po instalcji przypomina bardziej Silex’a niż jakąkolwiek z poprzednich wersji frameworka. Domyślnie Symfony 4 ma tylko dwie zależności symfony/flex i symfony/framework-bundle. Wszystko inne jest opcjonalne i zarządzane z poziomu Symfony Flex co pozwala na rozbudowę frameworka w dowolny sposób.
Możemy zatem stworzyć REST API dla aplikacji mobilnej bez konieczności usuwania komponentów, które w poprzednich wersjach były domyślnie włączone, jak np. Twig, ORM czy Web Profiler. Jeśli jednak chcemy stworzyć aplikację typu „monolit” nic nie stoi na drodze aby doinstalować potrzebne komponenty.
A skoro już wspomniałem o Silexie, wygląda na to, że Symfony 4 będzie jego gwoździem do trumny https://www.reddit.com/r/PHP/comments/7gypvw/silex_eol_in_2018/.
Zmieniona struktura katalogów
Już wersja 3 frameworka Symfony wprowadziła strukturę katalogów wzorowaną na systemach z rodziny Unix, minimalizując przy tym liczbę podkatalogów. I tak w Symfony 3 pojawiły się katalogi bin/, src/ czy też var/.
Symfony 4 podąża tą ścieżką, wprowadzając katalogi config/ zamiast app/config/ i public/ zamiast web/. Oprócz tego wiele katalogów w Symfony 4 jest opcjonalnych i pojawiają się dopiero w momencie instalowania komponentów, jako katalogi najwyższego poziomu – tak jest między innymi z katalogami test/ i templates/.
Pliki app.php i app_dev.php zastąpiono standardowym plikiem index.php.
Konfiguracja oparta na zmiennych środowiskowych
W Symfony 4 zrezygnowano z pliku konfiguracyjnego parameters.yml na rzecz zmiennych środowiskowych.
Ten sposób konfigurowania aplikacji jest jedną z rekomendacji Application Manifesto oraz zalecany jest przez wiele platform hostingowych.
Takie podejście ma też na celu oddzielenie parametrów konfiguracyjnych od kodu a tym samym powinno ułatwić wdrażanie aplikacji na produkcję.
Koniec wsparcia dla HHVM
Prace nad wspraciem dla HHVM prowadzone były od 2013 r. W lipcu 2015 r. Symfony 2 oraz wszystkie komponenty posiadały pełne wsparcie dla HHVM. W tamtych czasach wsparcie dla HHVM było kluczowe. HHVM było o wiele szybsze niż PHP i zauważalne stało się odchodzenie od PHP na rzecz HHVM. To się jednak zmieniło z wydaniem PHP w wersji 7. Różnica wydajności HHVM w stosunku do PHP 7 nie była już tak znaczna, a faktyczna ilość aplikacji Symfony wykorzystujących wsparcie dla HHVM była bardzo mała i nie przekraczała 4%. Te czynniki oraz brak pełnej kompatybilności pomiędzy HHVM i PHP 7 spowodowały decyzję o zawieszeniu wsparcia dla HHVM.
Jak zmigrować z Symfony 3 do Symfony 4
Symfony 4 wymaga PHP przynajmniej w wersji 7.1, więc przed przystąpieniem do migracji najpierw musimy spełnić ten podstawowy warunek. Następnie uaktualniamy naszą aplikację do wersji Symfony 3.4. Każdą aplikację Symfony w wersji 3 bez większych problemów powinniśmy móc podnieść do najnowszej wersji w obrębie tzw. Major Release, zapewnia nam to Obietnica Wstecznej Kompatybilności, o której więcej można poczytać tutaj. Gdy nasza aplikacja zostanie podniesiona do wersji 3.4, kolejnym krokiem będzie wyeliminowanie przestarzałych zależności. Aby pomóc w ich wykryciu otwórz Symfony Profiler będąc w trybie DEV.
Czasami ostrzeżenia mogą pochodzić od zewnętrznych dostawców bibliotek lub bundli. Jeśli tak jest, sprawdź najpierw czy została wydana poprawka do tej biblioteki obsługująca Symfony 4.
Podczas uruchamiania testów jednostkowych nie mamy niestety komfortu skorzystania z Profilera, w tym miejscu z pomocą przychodzi nam symfony/phpunit-bridge. Po zainstalowaniu phpunit-bridge za pomocą komendy:
$: composer require --dev symfony/phpunit-bridge
uruchamiamy testy – teraz już powinniśmy otrzymać informację o przestarzałych metodach użytych w testach jednostkowych.
Czasami zdarza się, że nie możemy usunąć wszystkich przestarzałych zależności – w takim przypadku możemy użyć SYMFONY_DEPRECATIONS_HELPER, ustawiając jego wartość na weak.
Gdy już uporaliśmy się z poprawkami, możemy uaktualnić wersję Symfony za pomocą composer.json.
{
"require": {
"symfony/symfony": "^4.0",
},
}
$: composer update symfony/symfony
Jeśli podczas aktualizacji otrzymamy błędy mówiące o konieczności aktualizacji komponentów symfony/symfony, należy wtedy użyć następującej komendy:
$: composer update symfony/symfony --with-dependencies
Jeśli aktualizacja przebiegła pomyślnie zostały jeszcze dwa kroki do wykonania, by w pełni móc korzystać z Symfony 4.
Pierwszy z nich to przejrzenie pliku https://github.com/symfony/symfony/blob/master/UPGRADE-4.0.md. Sprawdź czy wymienione w nim zmiany dotyczą Twojej aplikacji.
Kolejny i ostatni krok to zmiana struktury katalogów. Jak pisałem wcześniej, Symfony 4 domyślinie korzysta z Flexa w celu zarządzania zależnościami. Flex do poprawnego działania wymaga konkretnej struktury katalogów. Niestety nie ma narzędzia, które zautomatyzowało by ten proces. Najlepiej jest podążać za instrukcją zawartą w dokumentacji: https://symfony.com/doc/current/setup/flex.html#upgrade-to-flex.
Podsumowanie
Symfony 4 to narzędzie, obok którego nie możesz przejść obojętnie w chwili, gdy zastanawiasz się jaki framework spełni najlepiej wymagania stawiane przez Twoją aplikację. Po odchudzeniu, 70% mniej kodu w porównaniu z Symfony 3, widać, że Symfony jest przygotowane, aby stać się podstawowym szkieletem aplikacji typu API. Lecz jeśli Twoja aplikacja ma być ogromnym monolitem lub aplikacją konsolową, Symfony 4 również świetnie spełni się w tej roli. Jak zwykle też, w przypadku Symfony, dokumentacja frameworka jest pełna i gotowa na czas, co bardzo ułatwia pracę szczególnie z nowymi funkcjonalnościami.
Podczas pracy z Symfony 4 po raz pierwszy miałem przyjemność używać Flexa. Jestem bardzo pozytywnie zaskoczony tym narzędziem. Dopóki nie wiedziałem o jego istnieniu, konfiguracja w sposób manualny nie wydawała mi się uciążliwa. Teraz jednak nie chciałbym już nigdy tego robić.
Symfony z każdą kolejną wersją wyznacza nowe standardy i tak jest też tym razem. Czas pokaże ile z nich stanie się normą w wytwarzaniu oprogramowania w oparciu o PHP.
Źródła:
https://symfony.com/blog/symfony-4-a-new-way-to-develop-applications
https://symfony.fi/page/symfony-3-vs-symfony-4-and-flex
